Broadcasting method and system based on SIP protocol and RTP protocol

Abstract

The invention belongs to the technical field of digital information transmission, and relates to a broadcasting method and system based on an SIP (Session Initiation Protocol) and an RTP (Real-time Transport Protocol). In the broadcasting method, at least one multicast address is established and configured for a terminal group when no broadcasting task exists, and terminal equipment in the terminal group is added into all multicast addresses; searching a target terminal group where a target terminal is located when a broadcast task exists, and selecting a target multicast address; sending a multicast quit command to a non-target terminal in the target multicast address, and sending a push stream to the target multicast address through an RTP protocol; and after the broadcast task is finished, adding the non-target terminal into the target multicast address. The broadcasting system comprises a dispatching host connected with an SIP server and a core switch, and further comprises an underground looped network, a plurality of looped network switches form annular connection through the underground looped network, one looped network switch is connected with the core switch, and other looped network switches are connected with terminal equipment. According to the invention, broadcast delay and broadcast missing are avoided, and the answering reliability of the terminal equipment is improved.

Description

Technical Field

[0001] The present invention belongs to the technical field of digital information transmission, and in particular relates to a broadcasting method and system based on the SIP protocol and the RTP protocol. Background Art

[0002] The Session Initiation Protocol (SIP) is an application-layer signaling protocol used to initiate, manage, and terminate real-time communication sessions. It is widely used in production scenarios such as underground mine communications, factory production instructions, and logistics and distribution scheduling. The Real-Time Transport Protocol (RTP) is a transmission protocol specifically designed for transmitting real-time data such as audio and video.

[0003] The mine broadcast system is an intelligent communication system with network broadcasting and intercom functions. It consists of a dispatch host installed above ground, a SIP server, broadcast terminals installed throughout the mine, a fiber optic network, and underground switches. The terminals can play background music, news, and promotional reports, thereby improving the production environment and enhancing information exchange. In the event of an emergency, ground-based dispatchers can use the dispatch host to send emergency notifications to the terminals underground, providing evacuation routes or directing personnel underground to evacuate. Underground personnel can also communicate with the dispatch host or other terminals through their terminals, thereby minimizing losses and reducing the impact of secondary disasters during post-disaster rescue efforts.

[0004] When the same content needs to be broadcast to multiple end devices, multicast is typically used. The scheduling host establishes a multicast address and sends a "join multicast" command to the end devices. Upon receiving the command, these end devices return an ACK field to the scheduling host, confirming their participation in the multicast. Simultaneously, the end devices must send an IGMP report to the router, which must process this "membership report" before forwarding the new multicast stream. The time required for this process is called "call establishment delay," which typically ranges from hundreds of milliseconds to several seconds. Once the multicast is established, the scheduling host simply sends a single copy of the data to the multicast address, which is then distributed through the routers to ensure that all end devices within the multicast receive the information.

[0005] Existing broadcast methods suffer from the following issues: establishing a multicast session strictly relies on a request-response confirmation process. Underground working conditions are complex and harsh. High humidity, high vibration, and strong electromagnetic interference can reduce the reliability of communication optical cables. Tunnel cross-sections, branches, and other structural factors can cause radio signals to attenuate more rapidly. This results in poorer signal conditions for underground mine broadcast systems than for conventional communication systems, leading to more frequent delays and packet loss. During the multicast establishment phase, if data is lost during the "join multicast" command sent to a terminal device or the ACK packet sent back by the terminal device, the multicast establishment will fail. If the dispatching host times out and does not receive an ACK, it must resend the "join multicast" command and wait for the terminal device's ACK again. The retransmission interval increases with the number of retransmissions (exponential backoff), until the preset maximum number of retransmissions is exceeded. Terminal devices that have not received an ACK will be unable to join the multicast, resulting in missed broadcasts. Furthermore, after receiving the "join multicast" command, the terminal device will experience program processing delays and IGMP protocol interaction delays. Typically, the greater the number of multicast terminals, the longer the call setup delay, often resulting in a delay of several seconds before the first media packet is played. If some terminals fail to respond due to malfunctions, the initial broadcast delay can reach tens of seconds. This high latency is unacceptable in situations requiring emergency broadcasts, such as disasters. It will seriously hinder the issuance of warnings and the scheduling of on-site evacuations, increasing disaster losses. Forcibly setting a shorter upper limit for the delay and, after a timeout, ignoring terminals not participating in the multicast and broadcasting directly, will significantly increase the missed broadcast rate, preventing underground personnel from receiving the broadcast and being unable to evacuate in time. Summary of the Invention

[0006] In order to solve the above technical problems, the present invention provides a broadcast method based on the SIP protocol and the RTP protocol, comprising the following steps: s01. Divide the terminal devices into multiple terminal groups. When there is no broadcast task, establish and configure at least one multicast address for each terminal group. Add all terminal devices in each terminal group to all multicast addresses of the corresponding terminal group. The terminal device refers to a device located at the end of a communication network that is capable of receiving and broadcasting a push stream. The broadcast task refers to a scheduling host specifying the terminal device that needs to perform the broadcast and sending a push stream to the specified terminal device. The push stream refers to a data packet encapsulated according to the RTP protocol. s02. When there is a broadcast task, find the target terminal group where the target terminal is located and select the target multicast address; send an exit multicast command to the non-target terminals in the target multicast address, and then send a push stream to the target multicast address through the RTP protocol; The target terminal refers to a terminal device that needs to perform broadcasting in a broadcast task; the target terminal group refers to a terminal group in which the target terminal is located; the non-target terminal refers to a terminal device that does not perform the broadcast task in the target terminal group; and the target multicast address refers to a multicast address used for sending a push stream in the broadcast task. s03, after the broadcast task is completed, the non-target terminal is re-added to the target multicast address.

[0007] The broadcast method based on the SIP protocol and the RTP protocol provided by the application realizes pre-established multicast and normal monitoring, specifies the non-target terminal to exit the multicast when the broadcast is needed, and re-adds the exited non-target terminal to the target multicast address after the sending of the push stream to the target multicast address is completed.

[0008] Preferably, in step s01, if the multicast addresses of the terminal group are more than one, the priority of each multicast address of the terminal group is set.

[0009] Preferably, in step s02, the selected target multicast address specifically includes: if the target terminal group has only one multicast address, the multicast address is the target multicast address; if the target terminal group has more than one multicast address, the target multicast address is determined according to the broadcast task priority and the multicast address priority.

[0010] Preferably, step s02 further includes: while the push stream is being sent, the non-target terminal is required to send back an exit multicast confirmation after receiving the exit multicast command; if the dispatch host does not receive the exit multicast confirmation within a timeout, the exit multicast command is re-sent; if the response is still not received after reaching the preset upper limit of the re-sending number, the dispatch host generates a terminal device non-response report.

[0011] Preferably, step s02 further includes: when the target terminal performs broadcasting, if the push stream from multiple target multicast addresses is received at the same time, the push stream from the target multicast address with higher priority is preferentially broadcasted, the broadcasting of other push streams is interrupted, and the other received push streams are buffered in the storage medium of the target terminal device; after the broadcasting of the push stream from the target multicast address with higher priority is completed, the buffered other push streams are broadcasted; if the target terminal performs broadcasting and receives a unicast call invitation, the broadcasting is interrupted and all the push streams are buffered; after the unicast call is completed, the buffered other push streams are broadcasted.

[0012] The application further provides a broadcast system based on the SIP protocol and the RTP protocol, which is used for realizing the above-mentioned broadcast method based on the SIP protocol and the RTP protocol, and includes a dispatch host, the dispatch host being an upper control host or other upper computer or upper control platform connected with a third party interface, the dispatch host being connected with a SIP server and a core switch; further including an underground ring network, a plurality of ring network switches being connected in a ring shape through the underground ring network; one of the ring network switches being connected with the core switch, and the other ring network switches being connected with at least one terminal device.

[0013] Preferably, the scheduling host is used to send multicast commands; the SIP server is used to implement multicast member control through SIP protocol commands, and is also used to establish unicast SIP calls between the scheduling host and terminal devices, or between terminal devices.

[0014] The beneficial effects of the present invention are: By "establishing a multicast address when there is no broadcast task, specifying non-target terminals to exit the multicast address when there is a broadcast task, and sending broadcast media through multicast", broadcast delays caused by call establishment delays are effectively avoided, and real-time performance is higher; missed broadcasts caused by multicast establishment failures are avoided, and the answering reliability of terminal devices is significantly improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The accompanying drawings are used to provide a further understanding of the present invention and constitute a part of the specification. Together with the embodiments of the present invention, they are used to explain the present invention and do not constitute a limitation of the present invention. In the accompanying drawings: Figure 1 Flowchart of a broadcasting method based on the SIP protocol and the RTP protocol according to the first embodiment of the present invention; Figure 2 This is a flowchart of the steps when the target terminal is located in multiple terminal groups according to the first embodiment of the present invention; Figure 3 This is a schematic diagram of the architecture of a broadcast system based on the SIP protocol and the RTP protocol according to the second embodiment of the present invention. DETAILED DESCRIPTION

[0016] The technical solution of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, but not all of the embodiments.

[0017] Example 1:

[0018] like Figure 1 As shown, the first embodiment of the present invention discloses a broadcast method based on the SIP protocol and the RTP protocol, comprising the following steps: s01. Divide the terminal devices into multiple terminal groups, establish and configure at least one multicast address for each terminal group when there is no broadcast task, and add all terminal devices in each terminal group to all multicast addresses of the corresponding terminal group.

[0019] The terminal device refers to a device located at the end of the communication network that can receive broadcasts and broadcast push streams, such as mining broadcast speakers, communication intercom hosts, etc. The broadcast task refers to the terminal device that needs to perform the broadcast specified by the scheduling host and sending the push stream to the designated terminal device, such as the staff making an emergency call through the scheduling host microphone, issuing scheduling instructions, or the daily scheduled broadcast of time, news broadcast or music playback on the scheduling host; the push stream refers to audio, video or other media encapsulated into data packets according to the RTP protocol. A multicast address can include multiple terminal devices, and a terminal device can also join and listen to multiple different multicast addresses at the same time.

[0020] Step s01 specifically includes: s011. Divide each terminal device into multiple terminal groups based on factors such as mine zoning or production habits.

[0021] For example, according to the working area where the terminal equipment is located, multiple terminal equipment located in working area A is divided into terminal group A, and multiple terminal equipment located in working area B is divided into terminal group B; or according to the personnel team corresponding to the terminal equipment, the terminal equipment is divided into excavation terminal group, mining terminal group, transportation terminal group, etc.

[0022] s012. When there is no broadcast task, the scheduling host sends a command to the SIP server to establish and allocate at least one multicast address for each terminal group; if the terminal group has more than one multicast address, the priority is set for each multicast address of the terminal group.

[0023] Establishing and allocating a multicast address specifically involves the following steps: The scheduling host sends a "establish multicast" request (an INVITE command) to the SIP server. The session description protocol portion of the INVITE command contains information such as the multicast address, a list of terminal devices, and the transport protocol. The multicast address is a Class D IP address (e.g., 239.1.1.1:5004). The terminal device list contains the IP addresses of all terminal devices that need to join the multicast address, i.e., all the terminal devices in the terminal group.

[0024] If more than one multicast address needs to be assigned to a terminal group, repeat the above "Create and assign multicast addresses" steps to obtain multiple multicast addresses, and set priorities for the multiple multicast addresses on the SIP server. For example, create and configure three different multicast addresses for the terminal group, and then set the three multicast addresses to high / medium / low priority respectively.

[0025] s013. According to the command of the scheduling host, the SIP server sends a "join multicast" request to all terminal devices in the terminal group. After receiving the request, the terminal device sends a 200 OK response to the SIP server to confirm joining the multicast. If the SIP server does not receive the joining multicast confirmation within the time limit, it will resend the "join multicast" request to the terminal device that did not respond. If there is still no response after reaching the preset retransmission limit, the SIP server will send a terminal device no response report to the scheduling host.

[0026] If terminal group A is assigned more than one multicast address, step s013 is performed for each multicast address, so that each terminal device in terminal group A joins all multicast addresses of terminal group A. For example, if there are five terminal devices in terminal group A and three multicast addresses are configured, each terminal device will join the three multicast addresses with high, medium, and low priorities, respectively.

[0027] The above-mentioned step s01 is executed when there is no broadcast task. Therefore, the call establishment delay caused by packet loss, network fluctuations, etc. in this process is acceptable. The delay at this time will not delay the broadcast task. If there is an unresponsive terminal device, the staff can be informed in time and perform maintenance before executing the broadcast task.

[0028] Existing broadcast systems typically use proprietary control protocols at the TCP application layer. These proprietary protocols typically only interoperate with the developer's own client or system. In contrast, the first embodiment of the present invention uses SIP protocol commands to establish multicast sessions and control devices within the multicast session. Because SIP is a well-established, standardized protocol for the communications industry and supports multicast signaling, it offers greater interoperability and compatibility, enabling easy integration with third-party control (for example, access to a group cloud system for broadcast scheduling) and facilitating rapid development and deployment.

[0029] Furthermore, setting a plurality of multicast addresses of different priorities for each terminal group can facilitate the execution of broadcast tasks of different priorities.

[0030] s02. When a broadcast task is requested, the target terminal group is searched for the target terminal and the target multicast address is selected. If the target terminal group has only one multicast address, that multicast address is used as the target multicast address. If the target terminal group has more than one multicast address, the target multicast address is determined based on the broadcast task priority and the multicast address priority. After determining the target multicast address, an "exit multicast" command is sent to non-target terminals within the target multicast address, and then a push stream is sent to the target multicast address via the RTP protocol.

[0031] The target terminal refers to the terminal device that needs to perform broadcasting in this broadcast task; the target terminal group refers to the terminal group where the target terminal is located; the non-target terminal refers to the terminal device in the target terminal group that does not perform this broadcast task, and the target multicast address refers to the multicast address used to send push streams in this broadcast task.

[0032] For example, suppose terminal group A is assigned three multicast addresses, with high, medium, and low priorities, respectively. Terminal group A contains five devices (denoted as A01-A05). A staff member needs to use the dispatch host to send an emergency notification to devices A01, A02, and A05. The dispatch host first locates terminal group A, where target devices A01, A02, and A05 reside, as the target terminal group. Because the emergency notification is a high-priority broadcast task, it selects the high-priority multicast address of terminal group A as the target multicast address. The dispatch host then locates non-target devices A03 and A04 within terminal group A. It then issues a command to the SIP server to "exit terminal devices A03 and A04 from the high-priority multicast for terminal group A." The SIP server then sends a BYE command to terminal devices A03 and A04, which contains the target multicast address. Upon receiving the BYE command, terminal devices A03 and A04 exit the target multicast address. At the same time, the dispatch host sends a push stream of the emergency notification via the RTP protocol to the high-priority multicast address of terminal group A. At this time, terminal devices A01, A02, and A05 will receive the push stream through the target multicast address and complete the broadcast. However, terminal devices A03 and A04 have exited the target multicast address and will not receive the push stream and will not perform the broadcast.

[0033] Sometimes the target terminals of a broadcast task may be distributed in multiple terminal groups. In this case, step s021 will find two or more target terminal groups. If the target terminals of a broadcast task are distributed in multiple target terminal groups, it is only necessary to perform the above s022 operation on multiple target multicast addresses respectively, and the commands for multiple terminal groups can be run in parallel without increasing the response time. Figure 2 As shown, assuming that the terminal devices that need to execute a broadcast task are terminal devices A01, A02, A05 in terminal group A and terminal devices B02 and B03 in terminal group B, the "Exit A terminal group high priority multicast / B terminal group multicast" command is sent to terminal devices A03, A04, B01 and B04 respectively, and then the push stream is sent to the target multicast address of terminal group A and terminal group B respectively.

[0034] To further improve reliability and avoid misbroadcasting on terminal devices that do not need to broadcast, after sending the "Exit Multicast" command to the non-target terminal in step s022 and while sending the push stream, the non-target terminal may be required to send back an "Exit Multicast" confirmation after receiving the "Exit Multicast" command. Specifically, the non-target terminal is required to send back a 200 OK confirmation to confirm the exit from the multicast after receiving the BYE command. If the SIP server does not receive the exit multicast confirmation within a timeout, the "Exit Multicast" command will be resent. If there is still no response after reaching a preset retransmission limit, the SIP server will send a notification to the scheduling host, and the scheduling host will generate a "Terminal Device No Response" report.

[0035] The above-mentioned "issuing exit multicast instruction - waiting for confirmation - resending after timeout" command is performed synchronously with "sending push stream to target multicast address", thus reducing misbroadcast to non-target terminals without reducing the broadcast speed.

[0036] If a non-target terminal fails to correctly receive the "Exit Multicast" command due to packet loss or network fluctuations, a brief misbroadcast may occur. However, upon receiving a retransmitted "Exit Multicast" command, the non-target terminal will immediately exit the multicast and cease broadcasting. This misbroadcast duration typically does not exceed one second and does not result in command miscommunication. If a non-target terminal fails to receive the "Exit Multicast" command after multiple retransmissions, this typically indicates a failure in the terminal device or its branch network. In this case, the terminal device will typically be unable to receive or broadcast the push stream from the multicast address, and similarly, no prolonged misbroadcast will occur.

[0037] Sometimes, a terminal device may receive push streams from different multicast addresses at the same time. For example, while daily news is being broadcast through a low-priority multicast address, an emergency notification broadcast is sent from a high-priority multicast address. At this time, the "high-priority insertion" mechanism should be executed.

[0038] Therefore, as a preferred solution, when the target terminal executes broadcasting, if it receives push streams from multiple target multicast addresses at the same time, it will give priority to broadcasting the push streams sent from the target multicast address with a higher priority, interrupt the broadcast of other push streams, and cache the other received push streams in the storage medium of this target terminal device; after the push stream broadcast of the higher priority target multicast address is completed, the other cached push streams will be broadcast; if the target terminal receives a unicast call invitation when executing broadcasting, the broadcast will be interrupted and all push streams will be cached. After the unicast call ends, the other cached push streams will be broadcast.

[0039] Mine broadcast systems typically feature one-to-one unicast SIP calling. After establishing a unicast call between the dispatch host and a terminal device (or between two terminal devices) via SIP, a direct IP call is established, rather than using RTP to send a push stream. This IP call offers the lowest latency and is often used in emergency situations requiring real-time communication. Therefore, the method of Example 1 of the present invention effectively prioritizes the unicast call, overriding all other push streams. Unicast SIP calling is a common technology used in existing mine broadcast systems, and its specific implementation is not detailed here.

[0040] s03. After the broadcast task is completed, the non-target terminals of this broadcast task are added to the target multicast address again. The specific steps include: After the broadcast task is completed, the scheduling host sends a command to the SIP server, which in turn sends an INVITE command to all non-target terminals in the broadcast task. The INVITE command contains information such as the target multicast address (i.e., the multicast address that the non-target terminal previously exited), the transport protocol, and other information. Upon receiving the command, the terminal device sends a 200 OK response to the SIP server, confirming its participation in the multicast. If the SIP server times out without receiving a 200 OK response, it resends the INVITE command to the unresponsive terminal device. If no response is received after a specified number of retries, the SIP server sends a terminal device no-response report to the scheduling host.

[0041] By utilizing the task-free period after the broadcast task is completed, non-target terminals that previously exited the multicast are added back to the target multicast address. The aforementioned call establishment delay of "terminal devices rejoining the multicast" does not delay the broadcast transmission. After joining the multicast, the terminal device can normally monitor the multicast address. Compared with the previous method of "temporarily creating a new multicast when a broadcast is needed," the broadcast method of Example 1 of the present invention avoids broadcast delays caused by call establishment delays, achieving higher real-time performance. It also avoids missed broadcasts caused by multicast establishment failures, significantly improving the reliability of terminal devices.

[0042] Example 2:

[0043] like Figure 3As shown, embodiment 2 of the present invention discloses a broadcast system based on the SIP protocol and the RTP protocol, which is used to implement the broadcast method based on the SIP protocol and the RTP protocol disclosed in embodiment 1 of the present invention, including: a scheduling host, the scheduling host is an uphole control host or a third-party host or a third-party control platform connected through a third-party interface, and the scheduling host is connected to the SIP server and the core switch; it also includes an underground ring network, and multiple ring network switches form a ring connection through the underground ring network; one ring network switch is connected to the core switch, and other ring network switches are connected to at least one terminal device; the terminal device refers to a device located at the end of the communication network, which can receive and broadcast RTP push streams, such as a mine broadcast communication host, a mine broadcast speaker, etc.

[0044] The dispatch host sends multicast commands, such as "add a specified terminal device to the multicast" or "exit a non-target terminal from the multicast." Upon receiving these commands, the SIP server controls multicast membership using SIP protocol commands. The SIP server also establishes unicast SIP calls between the dispatch host and terminal devices, or between terminal devices.

[0045] In the embodiments of the present invention, technical features not described in detail are all existing technologies or conventional technical means and will not be described in detail here.

[0046] Finally, it should be noted that the above embodiments are only specific implementation methods of the present invention, which are used to illustrate the technical solutions of the present invention, rather than to limit them, and the protection scope of the present invention is not limited thereto. Those skilled in the art should understand that any person skilled in the art can modify or easily think of changes to the technical solutions described in the above embodiments within the technical scope disclosed by the present invention, or make equivalent replacements for some of the technical features therein; and these modifications, changes or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included in the protection scope of the present invention.

Claims

1. A broadcasting method based on SIP protocol and RTP protocol, characterized in that: The following steps are involved: s01. Divide the terminal devices into multiple terminal groups. When there is no broadcast task, establish and configure at least one multicast address for each terminal group. Add all terminal devices in each terminal group to all multicast addresses of the corresponding terminal group. The terminal device refers to a device located at the end of a communication network that is capable of receiving and broadcasting a push stream. The broadcast task refers to a scheduling host specifying the terminal device that needs to perform the broadcast and sending a push stream to the specified terminal device. The push stream refers to a data packet encapsulated according to the RTP protocol. s02. When there is a broadcast task, find the target terminal group where the target terminal is located and select the target multicast address; send an exit multicast command to the non-target terminals in the target multicast address, and then send a push stream to the target multicast address through the RTP protocol; The target terminal refers to the terminal device that needs to perform broadcasting in the broadcast task; the target terminal group refers to the terminal group where the target terminal is located; the non-target terminal refers to the terminal device in the target terminal group that does not perform the broadcast task; the target multicast address refers to the multicast address used to send the push stream in the broadcast task; s03. After the broadcast task is completed, the non-target terminals are added to the target multicast address again.

2. A broadcasting method based on SIP protocol and RTP protocol according to claim 1, characterized in that: In step s01, if the terminal group has more than one multicast address, a priority is set for each multicast address of the terminal group.

3. A broadcasting method based on SIP protocol and RTP protocol according to claim 1, characterized in that: In step s02, the target multicast address is selected specifically including: if the target terminal group has only one multicast address, then the multicast address is the target multicast address; if the target terminal group has more than one multicast address, then the target multicast address is determined according to the broadcast task priority and the multicast address priority.

4. A broadcasting method based on SIP protocol and RTP protocol according to claim 3, characterized in that: Step s02 also includes: while sending the push stream, requiring the non-target terminal to send back an exit multicast confirmation after receiving the exit multicast command; if the scheduling host does not receive the exit multicast confirmation within the time limit, the exit multicast command will be resent; if there is still no response after reaching the preset retransmission limit, the scheduling host will generate a terminal device no response report.

5. A broadcasting method based on SIP protocol and RTP protocol according to claim 4, characterized in that: Step s02 also includes: when the target terminal executes broadcasting, if it receives push streams from multiple target multicast addresses at the same time, it will give priority to broadcasting the push stream sent by the target multicast address with a higher priority and interrupt the broadcast of other push streams, and cache the other received push streams in the storage medium of the target terminal device; after the push stream of the higher priority target multicast address is broadcast, the other cached push streams will be broadcast; if the target terminal receives a unicast call invitation when executing broadcasting, it will interrupt the broadcast and cache all push streams, and after the unicast call ends, it will broadcast the other cached push streams.

6. A broadcast system based on SIP protocol and RTP protocol, characterized in that: Used to implement a broadcasting method based on the SIP protocol and the RTP protocol as described in claim 1, including a scheduling host, which is an uphole control host or other host computer or host control platform connected to a third-party interface, and the scheduling host is connected to a SIP server and a core switch; and also includes an underground ring network, wherein multiple ring network switches form a ring connection through the underground ring network; one of the ring network switches is connected to the core switch, and the other ring network switches are connected to at least one terminal device.

7. A broadcast system based on SIP protocol and RTP protocol according to claim 6, characterized in that: The scheduling host is used to send multicast commands; the SIP server is used to implement multicast member control through SIP protocol commands, and is also used to establish unicast SIP calls between the scheduling host and terminal devices, or between terminal devices.

Images