E1 link video conference terminal upgrading method and system

Abstract

The embodiment of the specification provides an E1 link video conference terminal upgrading method and system, wherein the method comprises the following steps: an MCU establishes an E1 upgrading conference, informs master nodes and slave nodes to enter a remote upgrading mode, each node stops audio and video transmission and returns to readiness; the MCU obtains version description information from the master node and sends the version description information to the ready slave nodes; the slave nodes perform model and version matching, if the model and version are matched and there is a difference, the slave nodes accept upgrading, otherwise, the slave nodes refuse; if there is a slave node accepting upgrading, the MCU controls the master node to divide firmware fragments and transmit the firmware fragments to the MCU through the E1 link, the MCU caches and distributes the firmware fragments to corresponding slave nodes after verification; the slave nodes perform backup programming according to programming addresses and report confirmations after verification; the MCU updates the progress according to the confirmations and responds to retransmission requests; after upgrading is completed, the MCU sends an end message and restores an audio and video conference, and sends a switching message to the upgraded slave nodes, and the slave nodes switch to backup upgrading surfaces and restart new versions.

Description

Technical Field

[0001] This document relates to the field of communication technology, and in particular to an E1 link video conferencing terminal upgrade method and system. Background Technology

[0002] E1 links are a widely adopted high-reliability digital communication standard in video conferencing systems. In a video conferencing system consisting of a master node terminal, an MCU (Multipoint Control Unit), and multiple slave node terminals, firmware upgrades are essential to ensure system functionality and security. However, existing technologies have the following problems: First, traditional upgrade methods often rely on maintenance personnel to carry upgrade files to each terminal site for local operation, which is inefficient. Especially when there are many nodes or they are scattered, the upgrade time and manpower costs increase significantly.

[0003] Second, some solutions attempt to perform remote upgrades via E1 links. However, E1 links have limited bandwidth, while firmware files are often large. Direct transmission would occupy the link for a long time, severely impacting normal audio and video conferencing services. Furthermore, E1 link transmission may encounter bit errors, and existing solutions lack reliable fragmentation verification and retransmission mechanisms. If an error occurs, the entire file often needs to be retransmitted, further exacerbating bandwidth pressure and upgrade time.

[0004] Third, existing remote upgrade solutions typically require all terminals to exit conference mode, stop audio and video encoding / decoding, and rejoin the conference after the upgrade is complete, resulting in long conference interruptions and a poor user experience. Furthermore, when switching between different upgrade versions or upgrading different modules, it often requires re-initializing or restarting the upgrade service, making it impossible to reuse the upgrade engine and resulting in high switching costs.

[0005] Fourth, the existing solution lacks the ability to intelligently schedule multiple slave nodes in batches, and cannot match them according to the current version and hardware model of each terminal, which can easily lead to erroneous or duplicate upgrades. At the same time, it lacks fine-grained control over fragmented transmission, making it difficult to ensure the reliability and efficiency of upgrades in narrowband E1 link environments.

[0006] Therefore, how to utilize the E1 link to achieve efficient, reliable, and low-interruption remote batch upgrades of video conferencing terminals, and to realize upgrade engine reuse and fragment-level retransmission control during the upgrade process, has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0007] This specification provides one or more embodiments of an E1 link video conferencing terminal upgrade method, including: S1. Establish an E1 upgrade conference through the MCU, including the master node and the slave node terminal to be upgraded, and notify each node to enter the remote upgrade mode. At this time, each node stops audio and video transmission and returns to the ready state to the MCU. S2. Obtain version description information from the master node through the MCU, and send the version description information to the ready slave node terminal; instruct the slave node terminal to match its own model and current version with the version description information. If a match is found and there is a version difference, return an accept upgrade message; otherwise, return a reject upgrade message. S3. Determine if there is a slave node terminal that accepts the upgrade. If there is, control the master node terminal through the MCU to divide the upgrade firmware into multiple fragments and transmit them to the MCU and slave node terminal in sequence through the E1 link. If the verification is successful, report the confirmation information. The MCU updates the progress according to the confirmation information and responds to the retransmission request. S4. After the upgrade is completed, the MCU sends an upgrade completion message to each node and resumes audio and video conferencing. Then, it sends a switch message to the upgraded slave node terminals, enabling the slave node terminals to switch to the backup upgrade interface and restart the new service version.

[0008] Furthermore, the version description information includes the product model, total version number, sharding verification algorithm, and the module name, module version number, burning start address, and burning size of each module; the upgrade acceptance message returned from the node terminal contains upgrade description information, which includes the number of modules to be upgraded and the module name, module version number, burning start address, and burning size of each module.

[0009] Furthermore, the master node terminal determines the segment transmission size based on the conference video bandwidth, divides the module image into several segments according to the segment transmission size, each segment contains a segment sequence number, segment content and segment check code, and sends it to the MCU through the video transmission channel of the E1 link, while caching the segments in the local queue.

[0010] Furthermore, the MCU-controlled master node terminal divides the upgrade firmware into multiple fragments and transmits them sequentially to the MCU and slave node terminals via the E1 link, specifically as follows: The MCU verifies the received fragments. If the verification is successful, it buffers and distributes them to the corresponding slave node terminal. If the verification fails, it initiates a retransmission to the master node. The node terminal verifies the received fragments. If the verification is successful, it backs up and burns the fragments according to the starting address and reports the confirmation information. If the verification fails, it initiates a retransmission to the MCU.

[0011] Furthermore, the retransmission request initiated by the MCU to the master node includes the module name and the fragment sequence number that needs to be retransmitted; the master node retrieves the corresponding fragment data packet from the cache queue according to the retransmission request and retransmits it.

[0012] Furthermore, the retransmission request initiated by the slave node terminal to the MCU includes the module name and the fragment sequence number that needs to be retransmitted; the MCU extracts the corresponding fragment data packet from the buffer queue according to the retransmission request and resends it to the slave node terminal.

[0013] Furthermore, in step S1, if the MCU does not receive a ready message from a node within a timeout period, it marks the node as not ready and stops upgrading it. This specification provides one or more embodiments of an E1 link video conferencing terminal upgrade system, including: Upgrade preparation module: used to establish an E1 upgrade conference through the MCU, including the master node and the slave node terminal to be upgraded, and notify each node to enter the remote upgrade mode. At this time, each node stops audio and video transmission and returns a ready state to the MCU. Version information distribution module: used to obtain version description information from the master node through the MCU and send the version description information to the ready slave node terminal; the slave node terminal is instructed to match its own model and current version with the version description information. If a match is found and there is a version difference, an upgrade acceptance message is returned; otherwise, an upgrade rejection message is returned. Firmware fragment transmission and burning module: used to determine whether there is a slave node terminal to receive the upgrade. If there is, the MCU controls the master node terminal to divide the upgrade firmware into multiple fragments and transmits them to the MCU and slave node terminal in sequence through the E1 link. If the verification is successful, the confirmation information is reported. The MCU updates the progress according to the confirmation information and responds to the retransmission request. Upgrade and Switching Module: After the upgrade is completed, the module sends an upgrade completion message to each node via the MCU and resumes audio and video conferencing. Then, it sends a switching message to the upgraded slave node terminals, enabling the slave node terminals to switch to the backup upgrade interface and restart the new service version.

[0014] This specification provides one or more embodiments of an electronic device, including: Processor; and, A memory is configured to store computer-executable instructions, which, when executed, cause the processor to implement the steps of the E1 link video conferencing terminal upgrade method described above.

[0015] This specification provides one or more embodiments of a storage medium for storing computer-executable instructions that, when executed, implement the steps of the E1 link video conferencing terminal upgrade method described above.

[0016] By employing the embodiments of this invention, multiple slave nodes are centrally scheduled by an MCU, enabling remote batch upgrades without on-site operation, significantly improving efficiency and reducing costs. Establishing independent E1 upgrade conferences minimizes interruptions to conference services. Through fragmented transmission, verification, and bidirectional retransmission mechanisms, the sending end can accurately retransmit specified fragments from the cache, avoiding full retransmissions and ensuring high reliability on narrowband E1 links. Simultaneously, the master node provides version description information, and slave nodes intelligently match based on model and version, upgrading only the differing modules, and the switchover upgrade task does not require service restarts, reducing switching costs. A backup burning and switching mechanism is adopted, with new firmware written to the backup area; in case of switching failure, the original version can be rolled back, improving upgrade security. In summary, this solution achieves efficient, reliable, and low-interruption remote batch upgrades.

[0017] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

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

[0019] Figure 1 A flowchart illustrating an E1 link video conferencing terminal upgrade method provided for one or more embodiments of this specification; Figure 2 A schematic diagram illustrating the composition of an E1 link video conferencing terminal upgrade system provided for one or more embodiments of this specification; Figure 3 This is a schematic diagram of the structure of an electronic device provided for one or more embodiments of this specification. Detailed Implementation

[0020] To enable those skilled in the art to better understand the technical solutions in one or more embodiments of this specification, the technical solutions in one or more embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of the embodiments. Based on one or more embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of this document.

[0021] Method Implementation Examples According to an embodiment of the present invention, an E1 link video conferencing terminal upgrade method is provided. Figure 1 A flowchart illustrating an E1 link video conferencing terminal upgrade method provided for one or more embodiments of this specification is shown below. Figure 1 As shown, the E1 link video conferencing terminal upgrade method according to an embodiment of the present invention specifically includes: S1. Establish an E1 upgrade conference via the MCU, including the master node and the slave node terminal to be upgraded, and notify each node to enter the remote upgrade mode. At this time, each node stops audio and video transmission and returns to the ready state to the MCU.

[0022] First, preparations and session establishment are performed before the upgrade. When maintenance personnel need to upgrade multiple slave node terminals in the video conferencing system, they first install the complete upgrade firmware package onto the master node terminal via physical media and perform a local physical upgrade on the master node terminal. After the master node terminal completes the local upgrade, the maintenance personnel operate on the MCU's meeting control interface to mark the master node terminal and all slave node terminals to be upgraded in the current meeting. Based on this marking information, the MCU establishes a dedicated E1 upgrade meeting to prevent the large data packets generated during the upgrade process from causing stuttering or delays in ongoing audio and video calls. After the MCU establishes the upgrade meeting, it sends a notification to the master node and all slave node terminals to be upgraded simultaneously via meeting control messages, such as the E1_UPGRADE_C_REMOTEMODE command, requesting them to enter E1 remote upgrade mode. The MCU upgrade page displays the current upgrade status as "ready". Upon receiving this notification, each node terminal immediately ceases its current audio and video encoding and stream transmission, releasing all E1 link bandwidth for subsequent firmware transmission, and returns a ready message, such as E1_UPGRADE_R_READY, to the MCU. After sending the command to enter upgrade mode, the MCU starts a timer. If the MCU fails to receive a ready message from a node within the preset timeout period, it determines that the node is not ready for upgrade, marks its status as not ready, stops the upgrade operation for that node in subsequent processes, and simultaneously displays a message on the control panel indicating that the upgrade has failed.

[0023] S2. Obtain version description information from the master node via the MCU and send the version description information to the ready slave node terminal; instruct the slave node terminal to match its own model and current version with the version description information. If a match is found and there is a version difference, return an accept upgrade message; otherwise, return a reject upgrade message.

[0024] After receiving ready messages from all responding nodes, the MCU first sends a command, E1_UPGRADE_C_UPLOADVERINFO, to the master node terminal requesting the upload of version information. Upon receiving this command, the master node terminal parses and generates a detailed version description based on the target firmware version it is currently running. This description includes the product model, total version number, fragmentation verification algorithm, number of version modules, and the module name, version number, starting address, and size of each module. The upgrade acceptance message returned by the slave node terminal contains upgrade description information, including the number of version modules to be upgraded and the module name, version number, starting address, and size of each module. Subsequently, the master node terminal encapsulates this version description information in a response message, E1_UPGRADE_R_UPLOADVERINFO, and sends it back to the MCU.

[0025] After receiving and caching the version description information, the MCU parses the fragmentation verification algorithm and broadcasts an upgrade start command E1_UPGRADE_C_START to all slave nodes marked as ready. This command carries the complete version description information. Each slave node awaiting upgrade executes an upgrade matching decision process upon receiving the upgrade start command: First, the slave node compares the product model in the version description information with its own hardware model. If the models do not match, the firmware package is not suitable for the device, and the upgrade is rejected. Second, the slave node compares the fragmentation verification algorithm in the version description information with its supported algorithms. If they do not match, the upgrade is also rejected. Finally, the slave node compares the version numbers of each module in the version description information with the version numbers of the corresponding modules it is currently running. If the overall version number is higher, and at least one module's version number differs, an upgrade is required. After determining that an upgrade is needed, the slave node generates and caches a copy of the upgrade description information. The upgrade description information is extracted from the version description information, containing only the information of the modules that need to be upgraded. Specifically, it includes: the number of modules in the version to be upgraded, and the name, version number, programming start address, and programming size of each module. Subsequently, the slave node terminal returns an upgrade acceptance message E1_UPGRADE_R_ACCCEPT to the MCU, the message content of which is the upgrade description information. Conversely, if the model does not match, the algorithm is not supported, or the versions are completely identical, the slave node terminal returns an upgrade rejection message E1_UPGRADE_R_REFUSE to the MCU. The MCU receives response messages from all slave node terminals. For nodes that return an upgrade acceptance message, its status is updated to "Upgrade in Progress," and its reported upgrade description information is cached; for nodes that return a rejection message or time out without response, its status is updated to "Upgrade Stopped." The MCU checks if there is at least one slave node terminal in the state of "to be upgraded". If it exists, it continues to the subsequent firmware upload stage; if it does not exist, the MCU directly sends an upgrade completion message E1_UPGRADE_C_FINISH to all nodes, notifying each node to resume the normal audio and video conferencing encoding and decoding process, and the entire upgrade process ends.

[0026] S3. Determine if there is a slave node terminal that accepts the upgrade. If so, control the master node terminal through the MCU to divide the upgrade firmware into multiple fragments and transmit them sequentially to the MCU and slave node terminals through the E1 link. If the verification is successful, report the confirmation information. The MCU updates the progress according to the confirmation information and responds to the retransmission request.

[0027] After confirming the existence of slave nodes requiring upgrades, the MCU, based on previously cached version description information, sequentially sends upload commands (E1_UPGRADE_C_UPLOADVERIMG) to the master node for each module requiring upgrade, with each command explicitly specifying the module name to be uploaded. Upon receiving the upload command for the module firmware, the master node first determines the fragmentation parameters. Specifically, the master node probes the current E1 link's video conferencing bandwidth and determines a secure and efficient fragmentation transmission size accordingly. This fragmentation transmission size is the length of a data packet, and its structure includes: fragment sequence number, fragment content, and fragment checksum. Based on the determined fragmentation transmission size, the master node divides the complete image file of the corresponding module into multiple fragments. Subsequently, the master node returns a response message (E1_UPGRADE_R_UPLOADVERIMG) to the MCU, informing the MCU of the upcoming module name and the total number of fragments. Next, the master node terminal begins to read the segmented content one by one, packages it into segmented transmission packets according to the format of segment sequence number, segment content, and segment checksum, and continuously sends these data packets to the MCU through the video transmission channel of the E1 link. At the same time, in order to cope with possible retransmission requests, the master node terminal stores these sent segmented packets in a local buffer queue.

[0028] The MCU begins receiving version module fragment transmission packets from the video channel. For each received fragment packet, the MCU first calculates the fragment content according to the fragment verification algorithm agreed upon in the version description information, and compares the calculation result with the fragment verification code carried in the fragment packet to determine whether data errors or packet loss occurred during the transmission of the fragment. If the verification passes, the MCU caches the fragment packet in its own memory or storage, and determines which slave nodes need the module based on the previously cached upgrade description information of different slave nodes. For slave nodes that need the module, the MCU immediately distributes the fragment packet to them through the network. If the MCU fails to verify a fragment packet, it determines that the fragment transmission is erroneous. At this time, the MCU initiates a retransmission process to the master node terminal. Specifically, the MCU sends a retransmission message E1_UPGRADE_C_RETRANSMITVERIMG to the master node terminal, which explicitly includes the module name and the fragment sequence number of the erroneous fragment. Upon receiving a retransmission message, the master node terminal immediately retrieves the corresponding fragment data packet from its local cache queue based on the module name and fragment sequence number, and resends it to the MCU. The MCU repeats the above process of receiving, verifying, distributing, and retransmitting until all fragments of the module have been completely and correctly received and distributed. During the entire module upload process, the MCU can also perform statistics based on the total number of received fragment packets and display the progress percentage of the version upload in real time on the control interface, facilitating monitoring by operations and maintenance personnel.

[0029] For each slave node terminal, the one awaiting upgrade continuously listens for and receives video channel version module fragment transmission packets distributed by the MCU. For each received fragment packet, the slave node terminal also performs data integrity verification using the agreed fragment verification algorithm. If the verification passes, the slave node terminal will process the upgrade using a backup method: based on the module's programming start address in the previously cached upgrade description information, as well as the current fragment sequence number and fragment content size, it calculates the specific physical address where the fragment data should be written to the storage chip, and then directly writes the fragment content to that address (spare storage area). After programming is complete, the slave node terminal reports a receive confirmation message E1_UPGRADE_R_RECVVERIMG to the MCU, which includes the module name and the fragment sequence number that was just programmed. If a slave node fails to verify a fragment packet, it will not proceed with the programming. Instead, it will initiate a retransmission request to the MCU. Specifically, it will send a retransmission message, E1_UPGRADE_C_RETRANSMITVERIMG, to the MCU, explicitly including the module name and the sequence number of the erroneous fragment. Upon receiving the retransmission message from the slave node, the MCU will retrieve the corresponding fragment data packet from its own cached fragment queue and resend it to the slave node. After receiving the E1_UPGRADE_R_RECVVERIMG confirmation messages from each slave node, the MCU will update the upgrade progress of each slave node in real time based on the fragment sequence number and the total number of fragments for that module, and this progress will be displayed on the interface.

[0030] The MCU and each slave node terminal will repeatedly perform the above-described process of receiving, verifying, programming, confirming, and retransmitting fragments until all fragments of the module have been successfully received and programmed by all slave node terminals that need to be upgraded. Then, the MCU will move on to the next module and repeat the entire process until all modules in the version description information have been processed.

[0031] S4. After the upgrade is completed, the MCU sends an upgrade completion message to each node and resumes audio and video conferencing. Then, it sends a switch message to the upgraded slave node terminals, enabling the slave node terminals to switch to the backup upgrade interface and restart the new service version.

[0032] After all modules requiring upgrades have been transmitted and burned, the MCU first sends an upgrade completion message, E1_UPGRADE_C_FINISH, to all nodes. Upon receiving this message, each node resumes its normal audio and video encoding / decoding process, rejoins the video conference, and returns the E1 link to the conference service. Subsequently, the MCU sends a switching instruction, E1_UPGRADE_C_SWITCH, to all upgraded slave nodes. This instruction triggers the slave nodes to start the new service version. Each slave node receiving the switching instruction automatically maps its system boot address to the backup upgrade interface (i.e., the backup storage area) that was just burned, and then performs a reboot. After rebooting, the terminal loads the new firmware version, completing the final switch from the old version to the new version.

[0033] The beneficial effects of this invention are as follows: By centrally scheduling multiple slave nodes through the MCU, remote batch upgrades are achieved without on-site operation, significantly improving efficiency and reducing costs. Establishing independent E1 upgrade conferences minimizes interruptions to conference services. Through fragmented transmission, verification, and bidirectional retransmission mechanisms, the sending end can accurately retransmit specified fragments from the cache, avoiding full retransmissions and ensuring high reliability on narrowband E1 links. Simultaneously, the master node provides version description information, and slave nodes intelligently match based on model and version, upgrading only the differing modules, and the switchover upgrade task does not require service restarts, reducing switchover costs. A backup burning and switching mechanism is adopted, with new firmware written to the backup area; in case of switchover failure, the original version can be rolled back, improving upgrade security. In summary, this solution achieves efficient, reliable, and low-interruption remote batch upgrades.

[0034] System Implementation Examples According to an embodiment of the present invention, an E1 link video conferencing terminal upgrade system is provided. Figure 2 A schematic diagram illustrating the composition of an E1 link video conferencing terminal upgrade system provided in one or more embodiments of this specification, as shown below. Figure 2 As shown, the E1 link video conferencing terminal upgrade system according to an embodiment of the present invention specifically includes: Upgrade preparation module 20: Used to establish an E1 upgrade conference through the MCU, including the master node and the slave node terminal to be upgraded, and notify each node to enter the remote upgrade mode. At this time, each node stops audio and video transmission and returns a ready state to the MCU. Version information distribution module 22: used to obtain version description information from the master node through the MCU and send the version description information to the ready slave node terminal; the slave node terminal is instructed to match its own model and current version with the version description information. If a match is found and there is a version difference, an upgrade acceptance message is returned; otherwise, an upgrade rejection message is returned. Firmware fragment transmission and burning module 24: Used to determine whether there is a slave node terminal that accepts the upgrade. If there is, the MCU controls the master node terminal to divide the upgrade firmware into multiple fragments and transmits them to the MCU and slave node terminal in sequence through the E1 link. If the verification is successful, the confirmation information is reported. The MCU updates the progress according to the confirmation information and responds to the retransmission request. Upgrade and Switching Module 26: After the upgrade is completed, it sends an upgrade completion message to each node through the MCU and resumes audio and video conferencing. Then, it sends a switching message to the upgraded slave node terminal, so that the slave node terminal switches to the backup upgrade surface and restarts the new service version.

[0035] The embodiments of the present invention are system embodiments corresponding to the above method embodiments. The specific operation of each module can be understood by referring to the description of the method embodiments, and will not be repeated here.

[0036] Device Example 1 This invention provides an electronic device, such as... Figure 3 As shown, it includes: a memory 30, a processor 32, and a computer program stored in the memory 30 and executable on the processor 32. When the computer program is executed by the processor 32, it performs the following method steps: S1. Establish an E1 upgrade conference through the MCU, including the master node and the slave node terminal to be upgraded, and notify each node to enter the remote upgrade mode. At this time, each node stops audio and video transmission and returns to the ready state to the MCU. S2. Obtain version description information from the master node through the MCU, and send the version description information to the ready slave node terminal; instruct the slave node terminal to match its own model and current version with the version description information. If a match is found and there is a version difference, return an accept upgrade message; otherwise, return a reject upgrade message. S3. Determine if there is a slave node terminal that accepts the upgrade. If there is, control the master node terminal through the MCU to divide the upgrade firmware into multiple fragments and transmit them to the MCU and slave node terminal in sequence through the E1 link. If the verification is successful, report the confirmation information. The MCU updates the progress according to the confirmation information and responds to the retransmission request. S4. After the upgrade is completed, the MCU sends an upgrade completion message to each node and resumes audio and video conferencing. Then, it sends a switch message to the upgraded slave node terminals, enabling the slave node terminals to switch to the backup upgrade interface and restart the new service version.

[0037] Device Example 2 This invention provides a computer-readable storage medium storing an information transmission implementation program. When executed by a processor 52, the program performs the following method steps: S1. Establish an E1 upgrade conference through the MCU, including the master node and the slave node terminal to be upgraded, and notify each node to enter the remote upgrade mode. At this time, each node stops audio and video transmission and returns to the ready state to the MCU. S2. Obtain version description information from the master node through the MCU, and send the version description information to the ready slave node terminal; instruct the slave node terminal to match its own model and current version with the version description information. If a match is found and there is a version difference, return an accept upgrade message; otherwise, return a reject upgrade message. S3. Determine if there is a slave node terminal that accepts the upgrade. If there is, control the master node terminal through the MCU to divide the upgrade firmware into multiple fragments and transmit them to the MCU and slave node terminal in sequence through the E1 link. If the verification is successful, report the confirmation information. The MCU updates the progress according to the confirmation information and responds to the retransmission request. S4. After the upgrade is completed, the MCU sends an upgrade completion message to each node and resumes audio and video conferencing. Then, it sends a switch message to the upgraded slave node terminals, enabling the slave node terminals to switch to the backup upgrade interface and restart the new service version.

[0038] The computer-readable storage media described in this embodiment include, but are not limited to, ROM, RAM, disk, or optical disk.

[0039] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for upgrading an E1 link video conferencing terminal, characterized in that, include: S1. Establish an E1 upgrade conference through the MCU, including the master node and the slave node terminal to be upgraded, and notify each node to enter the remote upgrade mode. At this time, each node stops audio and video transmission and returns to the ready state to the MCU. S2. Obtain version description information from the master node via the MCU, and send the version description information to the ready slave node terminal; The slave node terminal is instructed to match its own model, current version and the version description information. If a match is found and there is a version difference, an upgrade acceptance message is returned; otherwise, an upgrade rejection message is returned. S3. Determine if there is a slave node terminal that accepts the upgrade. If there is, control the master node terminal through the MCU to divide the upgrade firmware into multiple fragments and transmit them to the MCU and slave node terminal in sequence through the E1 link. If the verification is successful, report the confirmation information. The MCU updates the progress according to the confirmation information and responds to the retransmission request. S4. After the upgrade is completed, the MCU sends an upgrade completion message to each node and resumes audio and video conferencing. Then, it sends a switch message to the upgraded slave node terminals, enabling the slave node terminals to switch to the backup upgrade interface and restart the new service version.

2. The method according to claim 1, characterized in that, The version description information includes the product model, total version number, sharding verification algorithm, and the module name, module version number, burning start address, and burning size of each module; the upgrade acceptance message returned from the node terminal contains upgrade description information, which includes the number of modules to be upgraded and the module name, module version number, burning start address, and burning size of each module.

3. The method according to claim 1, characterized in that, The master node terminal determines the segment transmission size based on the conference video bandwidth, divides the module image into several segments according to the segment transmission size, each segment contains a segment sequence number, segment content and segment check code, and sends it to the MCU through the video transmission channel of the E1 link, while caching the segments in the local queue.

4. The method according to claim 1, characterized in that, The MCU-controlled master node terminal divides the upgrade firmware into multiple fragments and transmits them sequentially to the MCU and slave node terminals via the E1 link, specifically as follows: The MCU verifies the received fragments. If the verification is successful, it buffers and distributes them to the corresponding slave node terminal. If the verification fails, it initiates a retransmission to the master node. The node terminal verifies the received fragments. If the verification is successful, it backs up and burns the fragments according to the starting address and reports the confirmation information. If the verification fails, it initiates a retransmission to the MCU.

5. The method according to claim 4, characterized in that, The retransmission request initiated by the MCU to the master node includes the module name and the fragment sequence number that needs to be retransmitted; the master node retrieves the corresponding fragment data packet from the buffer queue according to the retransmission request and retransmits it.

6. The method according to claim 4, characterized in that, The retransmission request initiated by the slave node terminal to the MCU includes the module name and the fragment sequence number that needs to be retransmitted; the MCU extracts the corresponding fragment data packet from the buffer queue according to the retransmission request and resends it to the slave node terminal.

7. The method according to claim 1, characterized in that, In step S1, if the MCU does not receive a ready message from a node within a timeout period, it marks the node as not ready and stops upgrading it.

8. An E1 link video conferencing terminal upgrade system, characterized in that, include: Upgrade preparation module: used to establish an E1 upgrade conference through the MCU, including the master node and the slave node terminal to be upgraded, and notify each node to enter the remote upgrade mode. At this time, each node stops audio and video transmission and returns a ready state to the MCU. Version information distribution module: used to obtain version description information from the master node through the MCU and send the version description information to the ready slave node terminal; The slave node terminal is instructed to match its own model, current version and the version description information. If a match is found and there is a version difference, an upgrade acceptance message is returned; otherwise, an upgrade rejection message is returned. Firmware fragment transmission and burning module: used to determine whether there is a slave node terminal to receive the upgrade. If there is, the MCU controls the master node terminal to divide the upgrade firmware into multiple fragments and transmits them to the MCU and slave node terminal in sequence through the E1 link. If the verification is successful, the confirmation information is reported. The MCU updates the progress according to the confirmation information and responds to the retransmission request. Upgrade and Switching Module: After the upgrade is completed, the module sends an upgrade completion message to each node via the MCU and resumes audio and video conferencing. Then, it sends a switching message to the upgraded slave node terminals, enabling the slave node terminals to switch to the backup upgrade interface and restart the new service version.

9. An electronic device, characterized in that, include: processor; as well as, A memory configured to store computer-executable instructions, which, when executed, cause the processor to implement the steps of the E1 link video conferencing terminal upgrade method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, Used to store computer-executable instructions, which, when executed, implement the steps of the E1 link video conferencing terminal upgrade method as described in any one of claims 1 to 7.

Images