Conference remote disaster recovery method and system, computer equipment and readable storage medium

Abstract

The invention relates to a conference remote disaster recovery method and system, computer equipment and a readable storage medium. The method comprises the following steps: under the condition that a main center crashes, a secondary center reconstructs a current in-progress conference according to synchronized first conference data; wherein the synchronized first conference data is the conference data of the currently in-progress conference synchronized to the auxiliary center by the main center; and the auxiliary center receives the conference control signaling request of the auxiliary terminal corresponding to the auxiliary center, and establishes communication connection with the main terminal corresponding to the main center, so that the auxiliary terminal and the main terminal continue the current conference in the auxiliary center. By adopting the method, non-inductive conference joining of the terminal can be realized, so that the conference service efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of off-site disaster recovery technology, and in particular to a method, system, computer equipment, and readable storage medium for off-site disaster recovery of conferences. Background Technology

[0002] Off-site disaster recovery for meetings refers to the deployment of backup meeting systems or service nodes, such as secondary centers, in a remote location to prevent meeting interruptions caused by force majeure events such as system downtime, network outages, equipment failures, or natural disasters, in order to ensure the continuity and stability of the meeting when holding online or hybrid meetings.

[0003] In traditional technologies, for off-site disaster recovery of meetings, one site serves as the primary center and the other as a secondary or backup center. When the primary center experiences a connection failure, the secondary center takes over the meeting and continues to use its functions long-term. This requires the primary and secondary centers to have identical deployments and completely consistent functionality.

[0004] However, since meetings are continuous, when a meeting is interrupted, traditional technologies may cause the meeting to be interrupted during network segmentation. Terminals will need to reapply for the meeting after the network is restored, resulting in a poor meeting experience and low meeting service efficiency. Summary of the Invention

[0005] Therefore, it is necessary to provide a method, system, computer equipment, and readable storage medium for disaster recovery of meetings in different locations, which can enable seamless terminal entry into meetings and improve the efficiency of meeting services, in order to address the above-mentioned technical problems.

[0006] Firstly, this application provides a method for off-site disaster recovery for conferences, including:

[0007] In the event of a main center failure, the secondary center will reconstruct the currently ongoing meeting based on the synchronized first meeting data; the synchronized first meeting data is the meeting data of the currently ongoing meeting that was synchronized from the main center to the secondary center.

[0008] The secondary center receives the meeting control signaling request from the secondary terminal corresponding to the secondary center and establishes a communication connection with the primary terminal corresponding to the primary center, so that the secondary terminal and the primary terminal can continue the currently ongoing meeting in the secondary center.

[0009] In one embodiment, the main terminal includes a dual-login main terminal and a single-login main terminal; establishing a communication connection with the main terminal corresponding to the main center includes:

[0010] After the dual-login main terminal switches the crashed main login address to the secondary login address, the secondary center establishes a communication connection with the dual-login main terminal so that the dual-login main terminal can join the ongoing meeting in the secondary center;

[0011] The secondary center sends a re-invitation request for the ongoing meeting to the single-login primary terminal, enabling the single-login primary terminal to establish a communication connection with the secondary center and join the ongoing meeting in the secondary center.

[0012] In one embodiment, the method further includes:

[0013] If the main center's exit network is disconnected, the secondary center will reconstruct the currently ongoing meeting based on the synchronized first meeting data;

[0014] The secondary center receives the meeting control signaling request from the secondary terminal so that the secondary terminal can continue the currently ongoing meeting in the secondary center;

[0015] The main center continues to provide conference services to the main terminal, so that the main terminal can continue the currently ongoing conference in the main center.

[0016] In one embodiment, after establishing a communication connection with the main terminal corresponding to the main center, the above method further includes:

[0017] The main terminal switches the media access address that has crashed to the media access address of the secondary center, and the secondary center provides media services to the main terminal.

[0018] In one embodiment, the method further includes:

[0019] If the main center recovers, the main center will retrieve the meeting control data of the currently ongoing meetings from the secondary center and merge the data.

[0020] The secondary center continues to receive meeting control signaling requests from the secondary terminal and the primary terminal, and forwards these requests to the primary center so that the secondary terminal and the primary terminal can continue the currently ongoing meeting at the primary center.

[0021] In one embodiment, the method further includes:

[0022] If the meeting continuing at the main center is currently in progress, the secondary center communicates with the main terminal to provide media services to the main terminal.

[0023] In one embodiment, the off-site disaster recovery system for meetings further includes business partitioning; after the secondary center reconstructs the currently ongoing meeting based on the synchronized first meeting data, the method further includes:

[0024] The secondary center receives the meeting control signaling request from the business terminal corresponding to the business partition, establishes a communication connection with the business terminal, and enables the business terminal to continue the currently ongoing meeting in the secondary center.

[0025] In one embodiment, the off-site disaster recovery system for conferences further includes a service partition; the above method also includes:

[0026] If the business partition detects that the network connection with both the main center and the secondary center has been lost, the business partition will reconstruct the currently ongoing meeting based on the synchronized second meeting data; wherein the synchronized second meeting data is the meeting data of the currently ongoing meeting synchronized from the main center to the business partition; the synchronized second meeting data is the same as the synchronized first meeting data.

[0027] The service partition receives the meeting control signaling request from the service terminal corresponding to the service partition, so that the service terminal can continue the currently ongoing meeting in the service partition;

[0028] The main center continues to provide conference services to the main and secondary terminals outside the business partition, so that the main and secondary terminals can continue the currently ongoing conference in the main center.

[0029] In one embodiment, the method further includes:

[0030] When the business partition and the main center are reconnected, the main center obtains the meeting control data of the currently ongoing meetings in the business partition and merges the data.

[0031] The main center receives the meeting control signaling request from the business terminal and establishes a communication connection with the business terminal so that the business terminal can continue the currently ongoing meeting at the main center.

[0032] Secondly, this application also provides a conference off-site disaster recovery system, including:

[0033] The main center is used to provide meeting services for currently ongoing meetings;

[0034] The secondary center is used to reconstruct the currently ongoing meeting based on the synchronized first meeting data in the event of a primary center failure; it receives meeting control signaling requests from the secondary terminals corresponding to the secondary center and establishes a communication connection with the primary terminals corresponding to the primary center, so that the secondary terminals and primary terminals can continue the currently ongoing meeting in the secondary center; wherein, the synchronized first meeting data is the meeting data of the currently ongoing meeting synchronized from the primary center to the secondary center.

[0035] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0036] In the event of a main center failure, the secondary center will reconstruct the currently ongoing meeting based on the synchronized first meeting data; the synchronized first meeting data is the meeting data of the currently ongoing meeting that was synchronized from the main center to the secondary center.

[0037] The secondary center receives the meeting control signaling request from the secondary terminal corresponding to the secondary center and establishes a communication connection with the primary terminal corresponding to the primary center, so that the secondary terminal and the primary terminal can continue the currently ongoing meeting in the secondary center.

[0038] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0039] In the event of a main center failure, the secondary center will reconstruct the currently ongoing meeting based on the synchronized first meeting data; the synchronized first meeting data is the meeting data of the currently ongoing meeting that was synchronized from the main center to the secondary center.

[0040] The secondary center receives the meeting control signaling request from the secondary terminal corresponding to the secondary center and establishes a communication connection with the primary terminal corresponding to the primary center, so that the secondary terminal and the primary terminal can continue the currently ongoing meeting in the secondary center.

[0041] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0042] In the event of a main center failure, the secondary center will reconstruct the currently ongoing meeting based on the synchronized first meeting data; the synchronized first meeting data is the meeting data of the currently ongoing meeting that was synchronized from the main center to the secondary center.

[0043] The secondary center receives the meeting control signaling request from the secondary terminal corresponding to the secondary center and establishes a communication connection with the primary terminal corresponding to the primary center, so that the secondary terminal and the primary terminal can continue the currently ongoing meeting in the secondary center.

[0044] The aforementioned off-site disaster recovery method, system, computer equipment, computer-readable storage media, and computer program products allow the secondary center to reconstruct the currently ongoing meeting based on the synchronized first meeting data when the main center fails. The secondary center receives meeting control signaling requests from its corresponding secondary terminals, enabling the secondary terminals to resume the ongoing meeting seamlessly. Simultaneously, as long as the secondary center establishes a communication connection with the corresponding primary terminal at the main center, the primary terminal can also resume the currently ongoing meeting seamlessly. Neither the primary nor secondary terminals need to re-login, ensuring seamless participation during disaster recovery and effectively improving meeting service efficiency. Furthermore, this application only synchronizes core data related to the PBX and meeting services (such as meeting configuration, participant list, and PBX extension rules), rather than all IM and cloud storage data, significantly saving data synchronization bandwidth and hardware resources. The main center uses unidirectional incremental synchronization to the secondary center / business partition, transmitting only changed data (such as new meetings or PBX configuration modifications), reducing redundant synchronization traffic and improving synchronization efficiency. Attached Figure Description

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

[0046] Figure 1 This is a schematic diagram of the structure of a conference off-site disaster recovery system in one embodiment;

[0047] Figure 2 This is a flowchart illustrating a disaster recovery method for off-site meetings in one embodiment;

[0048] Figure 3 A schematic diagram illustrating the data synchronization process for meeting configuration in the main center of one embodiment;

[0049] Figure 4 This is a schematic diagram of the data synchronization process of the main control center in one embodiment;

[0050] Figure 5 This is a schematic diagram illustrating the joining method of an AVC terminal in the main terminal in one embodiment;

[0051] Figure 6 This is a schematic diagram illustrating the joining method of the SVC terminal in the main terminal in one embodiment;

[0052] Figure 7 This is a schematic diagram of the disaster recovery process in the event of a main center outage in one embodiment;

[0053] Figure 8 This is a schematic diagram of the off-site disaster recovery system for conferences in another embodiment;

[0054] Figure 9 This is a schematic diagram of main center availability detection in one embodiment;

[0055] Figure 10 This is a schematic diagram of the dual login addresses of a dual-login main terminal in one embodiment;

[0056] Figure 11 This is a schematic diagram illustrating the local regeneration process of a service partition when the egress network is disconnected, as shown in one embodiment.

[0057] Figure 12 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0058] 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.

[0059] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0060] The off-site disaster recovery method for conferences provided in this application can be applied to, for example... Figure 1 The diagram shows a remote disaster recovery system for meetings. This system includes a main center 102 and a secondary center 104. The main center 102 is the primary service node that runs the system normally, handling core business operations. For example, the main center could be a resident UC (Unified Communications) deployment or a cloud deployment. The secondary center 104 is a backup service node for the main center. For example, the secondary center could be a resident UC deployment used for disaster recovery or a cloud deployment. The main terminal 106 communicates with the main center 102 via the network, and the secondary terminal 108 communicates with the secondary center 104 via the network. During the ongoing meeting, the main center 102 and the secondary center 104 will mutually probe their connections to other centers. If the secondary center 104 detects a failure in the main center 102, it will reconstruct the ongoing meeting based on the synchronized first meeting data. This synchronized first meeting data is the meeting data synchronized from the main center to the secondary center for the ongoing meeting. The secondary center 104 receives the meeting control signaling request from the secondary terminal 108 corresponding to the secondary center 104 and establishes a communication connection with the primary terminal 106 corresponding to the primary center 102, so that the secondary terminal 108 and the primary terminal 106 can continue the currently ongoing meeting in the secondary center 104.

[0061] The main terminal 106 and the secondary terminal 108 can be, but are not limited to, various personal computers, laptops, smartphones, SIP phones, and tablets. The main center 102 and the secondary center 104 can be a server cluster consisting of multiple physical servers.

[0062] In one exemplary embodiment, such as Figure 2As shown, a method for off-site disaster recovery of conferences is provided, which can be applied to... Figure 1 Taking the off-site disaster recovery system for conferences as an example, the explanation includes the following steps 202 to 204. Among them:

[0063] Step 202: In the event of a main center failure, the secondary center reconstructs the currently ongoing meeting based on the synchronized first meeting data; wherein, the synchronized first meeting data is the meeting data of the currently ongoing meeting synchronized from the main center to the secondary center.

[0064] Among them, main center downtime means that the conference service of the main center is unavailable and the communication connection between the main center and the outside world (such as the main terminal and the secondary center) is broken.

[0065] In some implementations, the main center deploys a complete unified communications service, including conferencing services and non-conferencing services such as instant messaging (IM) and cloud storage. The secondary center only needs to deploy the critical business services within the conferencing services, synchronizing only critical business service data from the main center. Conferencing control signaling requests, conferencing control message push traffic, and information query traffic will not be routed to the secondary center. The critical business services include the PBX (Private Branch Exchange) and the backend and storage services required for the core conferencing business. The core conferencing business includes conferencing control services, media services, conferencing recording services, and database services. The secondary center does not need to deploy non-conferencing services, avoiding the consumption of large amounts of memory and disk space, saving hardware resources. It also does not need to synchronize large amounts of IM and cloud storage data, saving bandwidth for data synchronization.

[0066] For example, during the process of the main center providing unified communication services for an ongoing meeting, the main center will synchronize key business service data to the secondary center, instead of synchronizing all business data. The key business service data synchronized to the secondary center is considered as the first synchronized meeting data, including meeting configuration data and meeting control data. The meeting configuration data is synchronized via a database service, while the meeting control data is synchronized via a dual-write Redis approach.

[0067] The main center's meeting configuration data synchronization process is as follows: Figure 3As shown, the main center-DB cluster refers to the DB service of the main center, and the secondary center-DB cluster refers to the DB service of the secondary center. All stored data in the main center DB cluster has a version field (the actual value is the insertion or update timestamp). The secondary center's universal business service selects a master node, which periodically requests incremental data from the main center's data-sync-service, including the tables to be synchronized and the starting version for synchronization. The main center's data-sync-service retrieves the incremental data by querying the corresponding tables in its local DB cluster and identifying data with versions greater than or equal to the specified starting version. This data is then returned to the secondary center's universal business service in a specific format, such as JSON. Upon receiving the returned incremental data, the secondary center's universal business service inserts it into its local DB cluster in batches.

[0068] The main center's meeting control data synchronization process is as follows: Figure 4 As shown, the Redis cluster in the main center reads the meeting control data generated by the meeting service in the main center, writes the meeting control data into its own Redis cluster, and synchronously writes the meeting control data to the Redis cluster in the secondary center.

[0069] Through Redis dual-write mechanism, the main center synchronizes control data, i.e., data of ongoing meetings (such as meeting status and media subscription relationships), to the secondary center in real time. This ensures that: if the main center fails, the secondary center can rebuild the meeting in seconds based on the synchronized data, without the terminal needing to rejoin; in a split-brain scenario, each branch can independently maintain the meeting using locally synchronized data, and the meeting data can be merged after the network recovers. In addition, the meeting data synchronized to the secondary center is completely consistent with that of the main center (such as terminal authentication tokens and meeting IDs), ensuring: at the signaling level, terminal meeting control requests are seamlessly processed by the secondary center, and the keep-alive mechanism is not interrupted; at the media level, terminals obtain multi-center SFU addresses in advance, and automatically switch media access points after the main center fails, avoiding audio and video stuttering.

[0070] The primary terminal communicates with the primary center via the network to join the ongoing meeting. The secondary terminal communicates with the secondary center via the network to join the ongoing meeting. The joining methods for primary and secondary terminals are identical. Both primary and secondary terminals include AVC (Advanced Video Coding) terminals and SVC (Scalable Video Coding) terminals. Media from AVC terminals accesses the meeting through an intermediary and requires AVC forwarding before joining. Media from SVC terminals joins directly without transcoding, using SVC subscription and forwarding.

[0071] For example, the joining method of the AVC terminal in the main terminal is as follows: Figure 5 As shown, the AVC terminal's AVC inbound signaling connects to the local center's intermediary service (UNIGS signaling intermediary (Unified Gateway Server) / UNIGW media intermediary (Unified Gateway)) via the H.323 protocol (ITU-T recommended protocol) or the SIP protocol (Session Initiation Protocol). Then, through the intermediary service, the AVC inbound signaling connects to the meeting control HTTP interface to generate an HTTP request, namely M-C22: meeting control message / push message (within the meeting). This request is then forwarded to the meeting control service of the actual service center through the cross-center HTTP proxy forwarding service (redundancy-control) component. The AVC terminal's AVC media connects to the local UniGW via H.323 or SIP protocols. The UniGW then converts the AVC to SVC media, connecting it to the local AVC media service, including SFU-MSS (Selective Forwarding Unit-Media Streaming Server) and SFU-MC (Selective Forwarding Unit-Media Controller). The media is then forwarded via a cross-center HTTP proxy service to the actual service provider's conferencing service. The AVC-to-SVC conversion refers to first decoding the media in AVC mode, then encoding it in SVC mode, and finally sending it to the SVC channel. Each center's media service has independent capabilities for detecting and forwarding media.

[0072] The joining method for the SVC terminal in the main terminal is as follows: Figure 6 As shown, the SVC terminal's meeting control signaling, i.e., meeting control messages / push messages, is accessed through Cloud-NG (a next-generation access gateway component). The traffic is then forwarded through a cross-center HTTP proxy forwarding service before reaching the meeting control service of the actual active center for processing. After a SVC terminal successfully joins the meeting, it receives multiple SFU access addresses (including media access from multiple centers). The SVC terminal tries these addresses sequentially according to the recommended order. If its current center fails, it can choose to access other centers. Specifically, the SVC terminal obtains the top media controller (TOPMC) upon joining the meeting and uses the message returned by the MC to join the media meeting. One SFU-MC + N SFU-MSS constitute the SVC access service within the center. Various SVC terminals joining the SVC media network can subscribe to each other to achieve media interoperability. Cloud-NG and the cross-center HTTP proxy forwarding service are inter-center forwarding proxy components.

[0073] During the ongoing meeting, the primary and secondary data centers will probe each other's connectivity with other data centers. If the secondary data center detects a primary data center outage, disaster recovery will be performed on the secondary data center, which will then provide critical business services. The disaster recovery process in the event of a primary data center outage is as follows: Figure 7 As shown, when a meeting is held at the main center, the main center and the secondary center use their respective deployed cross-center HTTP proxy forwarding services—namely, the cross-center HTTP proxy forwarding service-main and the cross-center HTTP proxy forwarding service-secondary—to probe each other. If the cross-center HTTP proxy forwarding service-secondary detects that the cross-center HTTP proxy forwarding service-main has timed out, it determines that the main center has crashed and notifies the secondary center's meeting control service to migrate to the secondary center for disaster recovery. The secondary center then reconstructs the currently ongoing meeting based on the synchronized first meeting data.

[0074] Step 204: The secondary center receives the meeting control signaling request from the secondary terminal corresponding to the secondary center and establishes a communication connection with the primary terminal corresponding to the primary center, so that the secondary terminal and the primary terminal can continue the currently ongoing meeting in the secondary center.

[0075] The primary terminal is a local terminal of the main center, physically connected to the main center or within the same local area network. The secondary terminal is a local terminal of the secondary center, physically connected to the secondary center or within the same local area network.

[0076] like Figure 7 As shown, the cross-center HTTP proxy forwarding service forwards the meeting control signaling requests from the secondary terminal to the meeting control service in the secondary center. This means the secondary center receives the secondary terminal's meeting control signaling requests, keeping the meeting alive with the secondary center's meeting control service, thus achieving meeting keep-alive and ensuring seamless signaling without meeting cancellation. The meeting control signaling requests can include meeting keep-alive and fetching meeting information. Simultaneously, since the media access address returned when the secondary terminal joined the meeting is preferentially from the secondary center, the secondary center continues to provide media services to the secondary terminal without any media disruption or meeting cancellation. For the primary terminal, since the primary center is down, the primary terminal cannot connect to it. Therefore, the secondary center establishes a communication connection with the primary terminal, allowing both the secondary and primary terminals to continue the ongoing meeting in the secondary center.

[0077] In the aforementioned off-site disaster recovery method for meetings, when the primary center fails, the secondary center reconstructs the currently ongoing meeting based on the synchronized primary meeting data. The secondary center receives meeting control signaling requests from its corresponding secondary terminals, allowing the secondary terminals to seamlessly continue the ongoing meeting. Simultaneously, as long as the secondary center establishes a communication connection with the corresponding primary terminal at the primary center, the primary terminal can also seamlessly continue the currently ongoing meeting. Neither the primary nor secondary terminals need to re-login to the meeting, ensuring that terminals remain unaffected and do not exit the meeting during disaster recovery, effectively improving meeting service efficiency.

[0078] The off-site disaster recovery method for conferences provided in this application embodiment can also be applied to, for example... Figure 8 The diagram shows a remote disaster recovery system for meetings. This system includes not only the main center 102 and the secondary center 104, but also a business partition 110. Business partition 110 is a backup partition for the main center, which can be a partition deployed using an onboard UC or a business partition deployed in a cloud environment, supporting local regeneration. Local regeneration means that the partition itself is functioning normally, but the outbound network is disconnected, and only partial services can be provided within the partition. Business terminals 112 connect to business partition 110 via the network. During the ongoing meeting, business partition 110 also probes its connection status with the main center 102 and the secondary center 104. Business terminals 112 can be, but are not limited to, various personal computers, laptops, smartphones, SIP phones, and tablets. Business partition 110 can be a server cluster consisting of multiple physical servers.

[0079] In an exemplary embodiment, the off-site disaster recovery system for the conference also includes a business partition and a local business terminal in the business partition; in step 202, after the secondary center reconstructs the currently ongoing conference based on the synchronized first conference data, the above method further includes: the secondary center receiving the conference control signaling request from the business terminal and establishing a communication connection with the business terminal so that the business terminal can continue the currently ongoing conference in the secondary center.

[0080] In some implementations, in the event of a main center failure, the cross-center HTTP proxy forwarding service component of the business partition will forward the meeting control signaling request of the business terminal to the meeting control service of the secondary center, so that the secondary center receives the meeting control signaling request of the business terminal, thereby realizing the communication connection between the secondary center and the business terminal, and the business terminal can continue the currently ongoing meeting in the secondary center.

[0081] For example, such as Figure 9 The diagram illustrates the primary center availability detection process. When the primary center is available, its cross-center HTTP proxy forwarding service forwards the primary terminal's meeting control signaling requests to the primary center's meeting control service. The secondary center and business partition's cross-center HTTP proxy forwarding services also forward their respective terminals' meeting control signaling requests to the primary center's meeting control service. When the primary center fails, the secondary center and business partition's cross-center HTTP proxy forwarding services also forward their respective terminals' meeting control signaling requests to the secondary center's meeting control service.

[0082] In this embodiment, when the main center fails, the secondary center reconstructs the currently ongoing meeting based on the synchronized first meeting data. The business partition forwards the meeting control signaling request of the business terminal to the secondary center, thereby establishing a communication connection with the business terminal. This allows the business terminal to continue the currently ongoing meeting without being notified and without having to log in again, ensuring that the business terminal can remain in the meeting without being notified during the disaster recovery process.

[0083] In an exemplary embodiment, the main terminal includes a dual-login main terminal and a single-login main terminal; establishing a communication connection with the main terminal corresponding to the main center includes: after the dual-login main terminal switches the failed main login address to the secondary login address, the secondary center establishes a communication connection with the dual-login main terminal so that the dual-login main terminal can join the current ongoing meeting of the secondary center; the secondary center sends a re-invitation request for the current ongoing meeting to the single-login main terminal so that the single-login main terminal can establish a communication connection with the secondary center and join the current ongoing meeting of the secondary center.

[0084] A dual-login primary terminal refers to a primary terminal that supports two login addresses: a primary login address and a secondary login address. The primary login address is the local access address, i.e., the main center address, while the secondary login address is the disaster recovery access address, i.e., the secondary center address. If the primary login address becomes unreachable, the secondary login address will be automatically tried. A single-login primary terminal only supports one login address, meaning that if the main center fails, access will be impossible.

[0085] In some implementations, after the primary center crashes, the primary login address currently logged into by the dual-login primary terminal also crashes. The dual-login primary terminal then switches to the secondary login address. After switching to the secondary login address, the secondary center establishes a communication connection with the dual-login primary terminal, enabling the dual-login primary terminal to join the ongoing meeting in the secondary center.

[0086] For single-login main terminals, after the main center goes down, they cannot re-register to the critical business services of the secondary center, and therefore cannot join the membership by account invitation. You can first try to invite them by an intermediary, and finally invite them by IP call (Internet Protocol Call) to establish a communication connection between the single-login main terminal and the secondary center, so that the single-login main terminal can be re-invited to join the membership.

[0087] For example, a dual-login main terminal includes an SVC terminal and a SIP phone, while a single-login main terminal includes an AVC terminal and a third-party terminal. A schematic diagram of the dual-login addresses for a dual-login main terminal can be shown as follows... Figure 10As shown, the primary login address of the dual-login main terminal is the main center address, and the secondary login address is the secondary center address. The primary login address of the dual-login secondary terminal is the secondary center address, and the secondary login address is the main center address. The primary login address of the dual-login business terminal is the business partition address, and the secondary login address is the main center address. Each center or partition's recording intermediary also includes two registration addresses: the primary registration address of the main center's recording intermediary is the main center address, and the secondary login address is the secondary center address. The primary registration address of the secondary center's recording intermediary is the secondary center address, and the secondary login address is the main center address. The primary registration address of the business partition's recording intermediary is the business partition address, and the secondary login address is the main center address.

[0088] Continue reading Figure 7 After the main center crashes, the SVC terminal will switch to the secondary login address after a period of time following the failure of keep-alive. Then, it will continue to keep-alive via control signaling by establishing a communication connection with the secondary center.

[0089] For AVC terminals that do not support dual login addresses, the meeting is rebuilt using the secondary center meeting control service. After a period of time, an invitation is first attempted via an intermediary method, and finally via an IP call re-invitation method to re-invite the client to the meeting.

[0090] In this embodiment of the application, since the on-premises deployment cannot have a stable cloud scheduling service address as the first hop for the terminal, as public cloud does, by setting up dual login main terminals and re-inviting single login main terminals, stable access of terminals in on-premises deployment can be achieved, while ensuring that various types of terminals do not leave the network.

[0091] Furthermore, after establishing a communication connection with the main terminal corresponding to the main center, the above method also includes: the main terminal switching the media access address that has crashed to the media access address of the secondary center, and the secondary center providing media services to the main terminal.

[0092] In some implementations, after the main center crashes and disaster recovery is transferred to the secondary center, the main terminal will try to access the media access address of the secondary center after the media keep-alive with the main center expires in a very short time. This will switch the crashed media access address to the media access address of the secondary center, thereby completing the media switchover and allowing the secondary center to provide media services to the main terminal.

[0093] For example, such as Figure 7 As shown, the media stream of the main terminal is switched to the sfu-mss of the secondary center, and the secondary center provides media services to the main terminal.

[0094] In this embodiment of the application, after the main terminal crashes at the main center, it can automatically switch to the media access address of the secondary center, which can realize automatic disaster recovery of media services.

[0095] In some embodiments, the above method further includes: when the main center recovers, the main center obtains the meeting control data of the currently ongoing meeting in the secondary center and performs data merging; the secondary center continues to receive meeting control signaling requests from the secondary terminal and the main terminal, and forwards the meeting control signaling requests from the secondary terminal and the main terminal to the main center, so that the secondary terminal and the main terminal continue the currently ongoing meeting in the main center.

[0096] In some implementations, after the secondary center detects the recovery of the primary center, its meeting control service switches the meeting back to the primary center. The secondary center no longer provides meeting services, and any created meetings end after a period of time. The primary center continues to provide full unified communication services for currently running meetings. The primary center's cross-center HTTP proxy forwarding service detects the recovery of the secondary center and other business partitions, determines that it has recovered from the disaster recovery, and notifies the primary center's meeting control service to rebuild the meeting according to the meeting migration strategy. In some implementations, the meeting merging process of the primary center in the event of primary center recovery is described in [reference needed]. Figure 7 The main center's meeting control service reads the meeting control data of the currently ongoing meetings from the secondary center's Redis, and reads the meeting data of the currently ongoing meetings from the business partition's Redis, then merges the read meeting data. The meeting control data includes meeting settings data, such as inviting new members during a split-brain scenario. Meeting settings data includes meeting layout, muting members, and enabling audio recording. After the data merging is complete, it indicates that the meeting reconstruction is complete. The main center's meeting control service sets the overall reconstruction completion status, writes it to the main center's Redis, and also writes this status twice to the secondary center's Redis. Upon receiving the overall reconstruction completion status information from the secondary center's meeting control service, the secondary center's cross-center HTTP proxy forwarding service continues to receive meeting control signaling requests from both the secondary and main terminals, forwarding these requests to the main center's meeting control service. This achieves seamless signaling between the secondary and main terminals, allowing them to continue the currently ongoing meeting at the main center.

[0097] Furthermore, the primary and secondary cross-center HTTP proxy forwarding services need to coordinate with each other before notifying the control panel so that both sides can perform migration and merging operations simultaneously at the same time to avoid failure.

[0098] For various terminals accessing the secondary center and business partitions, since the access center or partition has not changed, the terminals are unaware of the changes.

[0099] For primary terminals that have already been migrated to the secondary center for disaster recovery, the migration process will be seamless. However, from a resource utilization efficiency perspective, when there are no subsequent meetings, the primary terminals can be notified via operation and maintenance control commands to reconnect to the primary center address.

[0100] In some implementations, the meeting migration strategy is based on the meeting itself. For a meeting with a specific meeting ID, a meeting in one center is selected as the base according to a priority strategy: main center > secondary center > business partition. Based on the selected meeting members, members from other centers with the same meeting ID are directly added back; for meetings with different IDs (even though the meeting ID is the same, they are different meetings), the meeting control service of that center notifies the terminal to rejoin the meeting (the terminal receives the notification and a pop-up window allows the user to confirm). For meeting recording, if any of the selected meeting or other meetings in other centers with the same meeting ID starts recording, a new recording intermediary needs to be invited.

[0101] The priority strategy mainly refers to the meeting merging rules: when the same meeting identifier exists, the configuration of the higher-priority center is used first. For example, if both the main center and the business partition have the same meeting identifier, and the main center has recording enabled while the business partition has recording disabled, the higher-priority main center will be used after merging. If the main center does not have the same meeting identifier, but the business partition does, then the terminal will be the sole criterion.

[0102] In this embodiment, when the main center recovers, it obtains the meeting data of the currently ongoing meeting from the secondary center, merges the data, and receives meeting control signaling requests from the secondary terminal and the main terminal forwarded by the secondary center, so that the secondary terminal and the main terminal can continue the currently ongoing meeting in the main center. It can automatically switch back to the main center when the main center recovers, allowing the main center to continue providing complete unified communication services.

[0103] In an optional embodiment of the above method, the method further includes: when the meeting continued by the main center is a currently ongoing meeting, the secondary center communicates with the main terminal to provide media services to the main terminal.

[0104] In some implementations, if the meeting continuing at the main center is an ongoing meeting, and no new main terminal is added, media access will continue to be handled by the secondary center. That is, the secondary center will continue to communicate with the main terminal and provide media services. Since the main terminal does not switch media services, the efficiency of the main terminal's media services can be ensured.

[0105] In an optional embodiment of the above method, the method further includes: when a new meeting is started at the main center, the main center communicates with the main terminal to provide media services to the main terminal.

[0106] In some implementations, if the main center starts a new meeting, the main terminal will connect to the main center's media access address, and the main center will provide more complete media services to the main terminal.

[0107] In an optional embodiment of the above method, the method further includes: when the meeting continuing at the main center is a currently ongoing meeting, but a new main terminal is added, the secondary center communicates with the main terminal to provide media services to the main terminal, and the main center communicates with the new main terminal to provide media services to the new main terminal.

[0108] In some implementations, if the main center continues an ongoing meeting but a new primary terminal is added, the secondary center continues communication with the original primary terminal to provide media services. For the new primary terminal, it needs to connect to the main center's media access address, allowing the main center to provide more complete media services. This eliminates the need to switch existing media access addresses, ensuring the efficiency of media services for the primary terminal.

[0109] In an exemplary embodiment, the above method further includes a processing step in the event of a disconnection of the main center's egress network. This step includes: in the event of a disconnection of the main center's egress network, the secondary center reconstructs the currently ongoing conference based on the synchronized first conference data; the secondary center receives a conference control signaling request from the secondary terminal to enable the secondary terminal to continue the currently ongoing conference in the secondary center; and the main center continues to provide conference services to the primary terminal to enable the primary terminal to continue the currently ongoing conference in the main center.

[0110] In some implementations, if the main center's outbound network is disconnected, the main terminal in the main center can still connect to the local server. However, the server in the main center is isolated from the servers in other centers, causing other centers to migrate to the secondary center for disaster recovery. In this case, the brain splits into two unconnected branches: one is the main center branch, and the other is the secondary center branch outside the main center. Terminals on the same branch continue the meeting, while terminals on other branches are disconnected. That is, the main terminals within the main center branch continue the meeting in the main center, and the secondary terminals within the secondary center branch migrate to the secondary center for disaster recovery and continue the meeting.

[0111] In some implementations, the secondary center reconstructs the ongoing meeting based on the synchronized first meeting data, and receives meeting control signaling requests from the secondary terminals to allow the secondary terminals to seamlessly continue the meeting. The primary terminals within the primary center branches seamlessly continue the meeting at the primary center. If the primary center's egress network recovers, the primary center merges the meeting data from the independent meetings of each branch back into the primary center's meeting. The primary center receives meeting control signaling requests from the secondary terminals to allow them to seamlessly continue the meeting; since the primary terminals are already connected to the primary center, they continue the meeting, thus restoring the full meeting.

[0112] When a disaster recovery system for a conference is deployed with business partitions, in the event of a network outage at the main center, the resulting secondary branch (after a split-brain scenario) still includes the business terminals of the business partitions. These secondary terminals and business terminals within the secondary branch are then relocated to the secondary center for disaster recovery and to continue the conference. Once the main center's network outage is restored, the main center merges the conference data from the independent meetings of each branch back into the main center's conference. The main center receives meeting control signaling requests from the secondary terminals and business terminals, allowing them to seamlessly continue the conference at the main center. Since the main terminals are already connected to the main center, they continue the conference, thus restoring the entire conference.

[0113] From the perspective of end users, members of other branches will see that the member of that branch goes offline and leaves the meeting after a period of black screen and silence. After the main center's outbound network is restored, the video and sound will be restored automatically, and the member will rejoin the meeting.

[0114] In this embodiment, even when the main center's exit network is disconnected, it is possible to provide conference services to terminals within the two branches of the split-brain structure, ensuring that the terminals do not leave the conference throughout the entire process.

[0115] This application can also ensure that business terminals in a partition can continue their meetings even when the partition is regenerated locally.

[0116] In an exemplary embodiment, the method further includes: when a service partition detects that the network connection with both the main center and the secondary center is disconnected, the service partition reconstructs the currently ongoing meeting based on the synchronized second meeting data; wherein the synchronized second meeting data is the meeting data of the currently ongoing meeting synchronized from the main center to the service partition; the synchronized second meeting data is the same as the synchronized first meeting data; the service partition receives a meeting control signaling request from the service terminal corresponding to the service partition, so that the service terminal can continue the currently ongoing meeting in the service partition; the main center continues to provide meeting services to the main terminal and the secondary terminal outside the service partition, so that the main terminal and the secondary terminal can continue the currently ongoing meeting in the main center.

[0117] For example, in the event that the service partition's egress network is disconnected, the process for local partition regeneration is as follows: Figure 11 As shown, when the cross-center HTTP proxy forwarding service of the business partition fails to keep the primary and secondary centers alive (i.e., the network connection with both the primary and secondary centers is lost), it determines that its own outbound network is disconnected and switches to local regeneration through the business partition's meeting control service. In the case of local regeneration, it will also split into two unconnected branches: one branch is the business partition branch, and the other is the central branch outside the business partition. Terminals on the same branch continue the meeting, while terminals on other branches are disconnected. That is, business terminals within the business partition branch continue the meeting within the business partition, while primary and secondary terminals within the central branch outside the business partition continue the meeting in the primary center.

[0118] The business partition reconstructs the currently ongoing meeting based on the synchronized second meeting data. This synchronized second meeting data consists of critical business service data and is identical to the synchronized first meeting data. The business partition's cross-center HTTP proxy forwarding service forwards the meeting control signaling requests from business terminals to the business partition's meeting control service. This means the business partition receives the meeting control signaling requests from business terminals, ensuring the meeting remains active and unaffected by signaling interruptions or meeting cancellations. Simultaneously, since the media access address returned upon business terminal entry is preferentially from the business partition, the business partition continues to provide media services to business terminals, also unaffected by media interruptions or meeting cancellations.

[0119] In this embodiment, when the egress network of a business partition is disconnected and unable to connect to the main and secondary centers, local regeneration of the business partition is supported. This enables the business terminals within the business partition to provide conferencing services, ensuring that the business terminals within the partition can continue the meeting and that no business terminal leaves the meeting during the entire process. Furthermore, because the main center uses a Redis dual-write mechanism to synchronize ongoing meeting data (such as meeting status and media subscription relationships) to the business partition in real time, it ensures that: when the egress network of a business partition is disconnected, the business partition can rebuild the meeting within seconds based on the synchronized data, and the terminals do not need to rejoin the meeting; in a split-brain scenario, each branch can independently maintain the meeting using locally synchronized data, and the meeting data can be merged after the network is restored.

[0120] In an optional embodiment of the above method, the method further includes: when the service partition and the main center restore the connection, the main center obtains the meeting data of the currently ongoing meeting in the service partition and merges the data; the main center receives the meeting control signaling request from the service terminal and establishes a communication connection with the service terminal so that the service terminal can continue the currently ongoing meeting in the main center.

[0121] In some implementations, the process of migrating the meeting back to the main center when the egress network of the service partition is restored is described in the following documentation. Figure 11The cross-center HTTP proxy forwarding service of the business partition detects the recovery of the main center, i.e., it restores the connection with the main center. Determining that the main center has recovered, it notifies the business partition's meeting control service to migrate meeting control data back to the main center and ceases to provide meeting services; any meetings created will end after a certain period. The main center's cross-center HTTP proxy forwarding service detects the recovery of the business partition and determines that it has recovered from disaster recovery. It notifies the main center's meeting control service to merge the ongoing meeting data of this partition into a single meeting according to the meeting migration strategy. After the data merging is complete, indicating that the meeting reconstruction is complete, the main center's meeting control service sets the overall reconstruction complete status, writes it to the main center's Redis, and also writes this status twice to the business partition's Redis. Upon receiving the overall reconstruction complete status information from the business partition's meeting control service, the business partition's cross-center HTTP proxy forwarding service forwards the meeting control signaling requests from the business terminals to the main center's meeting control service. This allows the main center to receive the meeting control signaling requests from the business terminals, establishes a communication connection with the business terminals, and enables the business terminals to continue the meeting seamlessly from the main center, while the business partition's meeting ends. The main terminal and the secondary terminal are already connected to the main center. The main terminal and the secondary terminal continue the meeting, thereby restoring the full meeting.

[0122] Furthermore, the cross-center HTTP proxy forwarding services of the main center and business partitions need to negotiate with each other before the notification and control, so that both sides can perform migration and merging operations at the same time to avoid failure.

[0123] For various terminals accessing the service partition, since the access partition has not changed, the terminals are unaware of the changes.

[0124] Furthermore, when the main and secondary centers or business partitions hold independent meetings due to network split, the meeting data of each branch (such as new participants and meeting operations) will be merged into the main center according to the meeting priority strategy (main center > secondary center > business partition) after the network is restored, to ensure the uniformity of the global meeting status and avoid data conflicts.

[0125] When the network exit of a business partition is disconnected, local regeneration relies on the synchronized meeting data to maintain the meetings within the business partition; after the network is restored, the meeting data of the business partition can be migrated back to the main center, realizing the full automation of the "independent meeting → data merging" process and reducing manual intervention.

[0126] In this embodiment of the application, when the main center is restored, the main center merges the meeting data of the currently ongoing meetings in the business partition and receives the meeting control signaling request from the business terminal, so that the business terminal of the locally regenerated partition can return to the main center to continue the meeting without being noticed.

[0127] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0128] Based on the same inventive concept, this application also provides a conference off-site disaster recovery device for implementing the aforementioned conference off-site disaster recovery method. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations in one or more embodiments of the conference off-site disaster recovery device provided below can be found in the limitations of the conference off-site disaster recovery method described above, and will not be repeated here.

[0129] In one exemplary embodiment, a conference off-site disaster recovery system is provided, the structural diagram of which is shown below. Figure 1 As shown, it includes:

[0130] Main Center 102 is used to provide meeting services for currently ongoing meetings.

[0131] Sub-center 104 is used to reconstruct the currently ongoing meeting based on the synchronized first meeting data in the event of a failure of main center 102; receive meeting control signaling requests from sub-terminal 108 corresponding to sub-center 104, and establish a communication connection with main terminal 106 corresponding to main center 102, so that sub-terminal 108 and main terminal 106 can continue the currently ongoing meeting in sub-center 104; wherein, the synchronized first meeting data is the meeting data of the currently ongoing meeting synchronized from main center 102 to sub-center 104.

[0132] In one exemplary embodiment, the main terminal 106 includes a dual-login main terminal 106 and a single-login main terminal 106;

[0133] The dual-login master terminal 106 is used to switch the failed master login address to the secondary login address. After switching to the secondary login address, the secondary center 104 establishes a communication connection with the dual-login master terminal 106 so that the dual-login master terminal 106 can join the ongoing meeting of the secondary center 104.

[0134] The secondary center 104 is used to send a re-invitation request for the currently ongoing meeting to the single-login main terminal 106, so that the single-login main terminal 106 can establish a communication connection with the secondary center 104 and join the currently ongoing meeting of the secondary center 104.

[0135] In an exemplary embodiment, the secondary center 104 is configured to reconstruct the currently ongoing meeting based on the synchronized first meeting data when the egress network of the primary center 102 is disconnected; and to receive a meeting control signaling request from the secondary terminal 108 so that the secondary terminal 108 can continue the currently ongoing meeting in the secondary center 104.

[0136] The main center 102 is used to continue providing conference services to the main terminal 106 so that the main terminal 106 can continue the currently ongoing conference in the main center 102.

[0137] In one exemplary embodiment, the main terminal 106 is used to switch the media access address of the downtime center 104 to the media access address of the secondary center 104.

[0138] Sub-center 104 is used to provide media services to the main terminal 106.

[0139] In an exemplary embodiment, the main center 102 is configured to, upon recovery of the main center 102, acquire the meeting control data of the currently ongoing meeting in the secondary center 104 and merge the data; the secondary center 104 continues to receive meeting control signaling requests from the secondary terminal 108 and the main terminal 106, and forwards the meeting control signaling requests from the secondary terminal 108 and the main terminal 106 to the main center 102, so that the secondary terminal 108 and the main terminal 106 can continue the currently ongoing meeting in the main center 102.

[0140] In an exemplary embodiment, if the meeting continuing at the main center 102 is a currently ongoing meeting, the secondary center 104 is used to communicate with the main terminal 106 to provide media services to the main terminal 106.

[0141] In an exemplary embodiment, the conference off-site disaster recovery system also includes a service partition 110 and local service terminals 112 within the service partition 110, such as... Figure 8 As shown, where:

[0142] Sub-center 104 is used to receive meeting control signaling requests from business terminal 112 after reconstructing the currently ongoing meeting based on the synchronized first meeting data, and to establish a communication connection with business terminal 112 so that business terminal 112 can continue the currently ongoing meeting in sub-center 104.

[0143] In an exemplary embodiment, the conference off-site disaster recovery system also includes a service partition 110 and a local service terminal 112 in the service partition 110;

[0144] Service partition 110 is used to reconstruct the currently ongoing meeting based on the synchronized second meeting data when the network connection with both the main center 102 and the secondary center 104 is lost. The synchronized second meeting data is the meeting data of the currently ongoing meeting synchronized from the main center 102 to service partition 110. The synchronized second meeting data is the same as the synchronized first meeting data. Service partition 110 receives a meeting control signaling request from service terminal 112 so that service terminal 112 can continue the currently ongoing meeting in service partition 110.

[0145] The main center 102 is used to continue providing conference services to the main terminal 106 and the secondary terminal 108 outside the business partition 110, so that the main terminal 106 and the secondary terminal 108 can continue the currently ongoing conference in the main center 102.

[0146] In an exemplary embodiment, the main center 102 is configured to, when the connection between the service partition 110 and the main center 102 is restored, acquire the meeting control data of the currently ongoing meeting in the service partition 110 and merge the data; receive the meeting control signaling request from the service terminal 112 and establish a communication connection with the service terminal 112 so that the service terminal 112 can continue the currently ongoing meeting in the main center 102.

[0147] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 12 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores data such as conference data for ongoing meetings. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network. When the computer program is executed by the processor, it implements a remote disaster recovery method for conferences.

[0148] Those skilled in the art will understand that Figure 12The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0149] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0150] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.

[0151] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0152] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0153] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0154] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0155] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for off-site disaster recovery for conferences, characterized in that, The method, applied to a conference off-site disaster recovery system, which includes a main center and a secondary center, includes: In the event of a main center failure, the secondary center will reconstruct the currently ongoing meeting based on the synchronized first meeting data. The synchronized first meeting data refers to the meeting data of the currently ongoing meeting that is synchronized from the main center to the sub-center. The secondary center receives the meeting control signaling request from the secondary terminal corresponding to the secondary center and establishes a communication connection with the primary terminal corresponding to the primary center, so that the secondary terminal and the primary terminal can continue the currently ongoing meeting in the secondary center.

2. The method according to claim 1, characterized in that, The main terminal includes a dual-login main terminal and a single-login main terminal; Establishing a communication connection with the main terminal corresponding to the main center includes: After the dual-login main terminal switches the crashed main login address to the secondary login address, the secondary center establishes a communication connection with the dual-login main terminal so that the dual-login main terminal can join the ongoing meeting of the secondary center; The secondary center sends a re-invitation request for the currently ongoing meeting to the single-login primary terminal, so that the single-login primary terminal can establish a communication connection with the secondary center and join the currently ongoing meeting of the secondary center.

3. The method according to claim 1, characterized in that, The method further includes: If the main center's exit network is disconnected, the secondary center will reconstruct the currently ongoing meeting based on the synchronized first meeting data. The secondary center receives the meeting control signaling request from the secondary terminal, so that the secondary terminal can continue the currently ongoing meeting at the secondary center; The main center continues to provide conference services to the main terminal, so that the main terminal can continue the currently ongoing conference at the main center.

4. The method according to claim 1, characterized in that, After establishing a communication connection with the main terminal corresponding to the main center, the method further includes: The main terminal switches the media access address that has crashed to the media access address of the secondary center, and the secondary center provides media services to the main terminal.

5. The method according to claim 1, characterized in that, The method further includes: If the main center recovers, the main center obtains the meeting control data of the currently ongoing meeting from the secondary center and merges the data. The secondary center continues to receive meeting control signaling requests from the secondary terminal and the primary terminal, and forwards these requests to the primary center so that the secondary terminal and the primary terminal can continue the currently ongoing meeting at the primary center.

6. The method according to claim 5, characterized in that, The method further includes: If the meeting continuing at the main center is the currently ongoing meeting, the secondary center communicates with the main terminal to provide media services to the main terminal.

7. The method according to claim 1, characterized in that, The off-site disaster recovery system for the conference also includes a business partition and local business terminals within the business partition; after the secondary center reconstructs the currently ongoing conference based on the synchronized first conference data, the method further includes: The secondary center receives the meeting control signaling request from the service terminal and establishes a communication connection with the service terminal so that the service terminal can continue the currently ongoing meeting at the secondary center.

8. The method according to claim 1, characterized in that, The off-site disaster recovery system for the conference also includes a business partition and local business terminals within the business partition; the method further includes: If the service partition detects that the network connection with both the main center and the secondary center is lost, the service partition reconstructs the currently ongoing meeting based on the synchronized second meeting data; wherein, the synchronized second meeting data is the meeting data of the currently ongoing meeting synchronized from the main center to the service partition; the synchronized second meeting data is the same as the synchronized first meeting data; The service partition receives a meeting control signaling request from the service terminal, so that the service terminal can continue the currently ongoing meeting in the service partition; The main center continues to provide conference services to the main and secondary terminals outside the business partition, so that the main and secondary terminals can continue the currently ongoing conference at the main center.

9. The method according to claim 8, characterized in that, The method further includes: When the business partition and the main center reconnect, the main center obtains the meeting control data of the currently ongoing meeting in the business partition and performs data merging. The main data center receives the meeting control signaling request from the service terminal and establishes a communication connection with the service terminal so that the service terminal can continue the currently ongoing meeting at the main data center.

10. A conference off-site disaster recovery system, characterized in that, The system includes: The main center is used to provide meeting services for currently ongoing meetings; The secondary center is used to reconstruct the currently ongoing meeting based on the synchronized first meeting data in the event of a failure of the primary center; to receive meeting control signaling requests from the secondary terminal corresponding to the secondary center, and to establish a communication connection with the primary terminal corresponding to the primary center, so that the secondary terminal and the primary terminal can continue the currently ongoing meeting in the secondary center; wherein, the synchronized first meeting data is the meeting data of the currently ongoing meeting synchronized from the primary center to the secondary center.

Images