A broadcast method and system based on SIP protocol and RTP protocol

Abstract

The present application belongs to the technical field of digital information transmission, and relates to a broadcasting method and system based on SIP protocol and RTP protocol. In the broadcasting method, at least one multicast address is established and configured for a terminal group when there is no broadcasting task, and terminal devices in the terminal group are added to all multicast addresses; when there is a broadcasting task, a target terminal group where a target terminal is located is found, a target multicast address is selected, a non-target terminal in the target multicast address is sent an exit multicast command, and a push stream is sent to the target multicast address through the RTP protocol; and after the broadcasting task is completed, the non-target terminal is added to the target multicast address. The broadcasting system comprises a dispatch host connected with a SIP server and a core switch, and further comprises an underground ring network, a plurality of ring network switches form a ring connection through the underground ring network, one ring network switch is connected with the core switch, and the other ring network switches are connected with terminal devices. The present application avoids broadcasting delay and broadcasting missed broadcast, and improves the call reliability of the terminal devices.

Description

Technical Field

[0001] This invention belongs to the field of digital information transmission technology, and in particular relates to a broadcasting method and system based on SIP and RTP protocols. Background Technology

[0002] SIP (Session Initiation Protocol) 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 mining communications, factory production instruction issuance, and logistics distribution scheduling. RTP (Real-Time Transport Protocol) is a transmission protocol specifically designed for transmitting real-time data such as audio and video.

[0003] A mine broadcasting system is an intelligent communication system with functions such as network broadcasting and public address intercom. It consists of a dispatching host installed above ground, a SIP server, terminal equipment installed throughout the mine for broadcasting, a fiber optic network, and underground switches. The terminal equipment can play background music, news, and announcements, thereby improving the production environment and enhancing information exchange. In the event of an emergency, ground dispatchers can send emergency notifications to the underground terminal equipment via the dispatching host, indicating evacuation routes or issuing verbal instructions to personnel on site. Personnel on site underground can also communicate with the dispatching host or other terminal equipment through the terminal equipment, thereby reducing disaster losses and mitigating the impact of secondary disasters during post-disaster rescue operations.

[0004] When it's necessary to broadcast the same content to multiple terminal devices, multicast is typically used. The scheduling host establishes a multicast address and sends a "join multicast" command to the terminal devices. Upon receiving the command, these terminal devices send an ACK confirmation field back to the scheduling host, acknowledging their participation in the multicast. Simultaneously, the terminal devices need to send an IGMP report to the router. The router must process this "membership report" before it can begin forwarding the new multicast stream. The time required for this process is called the "call establishment delay," which typically ranges from hundreds of milliseconds to several seconds. After establishing the multicast, the scheduling host only needs to send one data packet to the multicast address to distribute it through the router, ensuring all terminal devices within the multicast receive the information.

[0005] The existing broadcasting methods described above have the following problems: Establishing a multicast session relies heavily on request and response confirmation. However, the complex and harsh underground working environment, with high humidity, high vibration, and strong electromagnetic interference, reduces the reliability of communication optical cables. Structural factors such as the cross-section and branches of the tunnel cause radio signals to attenuate more quickly, resulting in worse signal conditions for underground mine broadcasting systems compared to general communication systems, leading to more frequent delays and packet loss. During multicast establishment, if the "join multicast" command sent to the terminal device or the ACK confirmation packet returned by the terminal device experiences data packet loss, multicast establishment will fail. If the scheduling host does not receive an ACK confirmation within a timeout period, it needs to resend the "join multicast" command and wait for the terminal device's ACK confirmation again. The retransmission interval increases with the number of retransmissions (exponential backoff), until the preset maximum number of retransmissions is exceeded. Terminal devices that do not send back an ACK confirmation will be unable to join the multicast, resulting in missed broadcasts. Furthermore, there is a processing delay and IGMP protocol interaction delay after the terminal device receives the "join multicast" command. Generally, the more multicast terminal devices there are, the longer the call setup delay will be, often resulting in a delay of several seconds in the initial media playback time. If some terminal devices are unable to respond due to malfunction, the initial broadcast delay may reach tens of seconds. For situations requiring emergency broadcasts, such as disasters, this high delay is unacceptable, as it will severely hinder the issuance of warnings and the dispatch of on-site personnel evacuation, increasing disaster losses. If a short delay limit is forcibly set, and broadcasts are continued directly without regard to terminal devices not included in the multicast after the timeout, the missed broadcast rate will increase significantly, causing underground personnel to miss the broadcast and be unable to evacuate in time. Summary of the Invention

[0006] To address the aforementioned technical problems, this invention provides a broadcasting method based on SIP and RTP protocols, comprising the following steps:

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

[0008] The terminal device refers to a device located at the end of a communication network that can receive and broadcast push streams; the broadcast task refers to specifying the terminal device that needs to perform the broadcast through a scheduling host and sending push streams to the specified terminal device; the push stream refers to data packets encapsulated according to the RTP protocol.

[0009] s02. When there is a broadcast task, find the target terminal group where the target terminal is located, 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;

[0010] 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 to which the target terminal is located; the non-target terminal refers to the terminal device in the target terminal group that does not perform broadcasting tasks; and the target multicast address refers to the multicast address used to send push streams in the broadcast task.

[0011] s03. After the broadcast task is completed, add the non-target terminals back to the target multicast address.

[0012] The broadcasting method based on SIP and RTP protocols provided by this invention enables pre-establishment of multicast and normal monitoring. When broadcasting is required, non-target terminals are specified to exit the multicast, and after the push stream is sent to the target multicast address, the exited non-target terminals are rejoined.

[0013] Preferably, in step s01, if there is more than one multicast address for a terminal group, a priority is set for each multicast address of the terminal group.

[0014] Preferably, in step s02, selecting the target multicast address specifically includes: if the target terminal group has only one multicast address, then that 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.

[0015] Preferably, step s02 further includes: while sending the push stream, requiring non-target terminals 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 a timeout period, then resend the exit multicast command; if there is still no response after reaching the preset maximum number of resends, then the scheduling host generates a terminal device no-response report.

[0016] Preferably, step s02 further includes: when the target terminal performs broadcasting, if it simultaneously receives push streams from multiple target multicast addresses, it prioritizes broadcasting the push stream from the higher-priority target multicast address and interrupts the broadcasting of other push streams, and caches the other received push streams in the storage medium of the target terminal device; after the push stream from the higher-priority target multicast address has finished broadcasting, it broadcasts the other cached push streams; if the target terminal receives a unicast call invitation when performing broadcasting, it interrupts the broadcasting and caches all push streams, and after the unicast call ends, it broadcasts the other cached push streams.

[0017] This invention also provides a broadcast system based on SIP and RTP protocols to implement the aforementioned broadcast method based on SIP and RTP protocols. The system includes a scheduling host, which is either a surface control host or another host computer or host control platform connected via a third-party interface. The scheduling host is connected to a SIP server and a core switch. The system also includes an underground ring network, with multiple ring network switches forming a ring connection. One ring network switch is connected to the core switch, and the other ring network switches are connected to at least one terminal device.

[0018] 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 at the same time to establish unicast SIP calls between the scheduling host and terminal devices, or between terminal devices.

[0019] The beneficial effects of this invention are:

[0020] By establishing a multicast address when there is no broadcast task and specifying the exit address of non-target terminals when there is a broadcast task, and sending broadcast media through multicast, the broadcast delay caused by call establishment delay is effectively avoided, resulting in higher real-time performance; it also avoids missed broadcasts caused by multicast establishment failure, significantly improving the call reception reliability of terminal devices. Attached Figure Description

[0021] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings:

[0022] Figure 1 This is a flowchart of a broadcasting method based on SIP and RTP protocols according to Embodiment 1 of the present invention;

[0023] Figure 2 This is a flowchart illustrating the steps in Embodiment 1 of the present invention when the target terminal is located within multiple terminal groups;

[0024] Figure 3 This is a schematic diagram of the architecture of a broadcast system based on SIP and RTP protocols according to Embodiment 2 of the present invention. Detailed Implementation

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

[0026] Example 1:

[0027] like Figure 1 As shown, Embodiment 1 of the present invention discloses a broadcasting method based on the SIP and RTP protocols, comprising the following steps:

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

[0029] The terminal device refers to a device located at the end of the communication network that can receive broadcasts and transmit broadcast streams, such as a mine broadcast speaker or a communication intercom host. The broadcast task refers to specifying the terminal device to be broadcast to and sending a stream to the specified terminal device through a scheduling host. Examples include staff using the scheduling host microphone to make emergency announcements or issue scheduling instructions, or the scheduling host broadcasting time announcements, news broadcasts, or music playback at regular intervals. The 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 single terminal device can join and simultaneously listen to multiple different multicast addresses.

[0030] Step s01 specifically includes:

[0031] s011. Based on factors such as mine zoning or production habits, each terminal device is divided into multiple terminal groups.

[0032] For example, based on the work area where the terminal equipment is located, multiple terminal equipment located in work area A are classified as terminal group A, and multiple terminal equipment located in work area B are classified as terminal group B; or based on the personnel shifts corresponding to the terminal equipment, the terminal equipment can be classified as tunneling terminal group, mining terminal group, transportation terminal group, etc.

[0033] 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 a terminal group has more than one multicast address, then the priority of each multicast address of the terminal group is set.

[0034] Establishing and allocating a multicast address specifically includes the following steps: The scheduling host sends a "establish multicast" request to the SIP server. This request is an INVITE command. 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 list of terminal devices records the IP addresses of all terminal devices that need to join the multicast address, that is, the IP addresses of all terminal devices within the terminal group.

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

[0036] 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 join multicast confirmation within the timeout period, it resends the "join multicast" request to the unresponsive terminal device. If there is still no response after reaching the preset resend limit, the SIP server sends a terminal device no response report to the scheduling host.

[0037] If terminal group A is assigned more than one multicast address, then step s013 is executed for each multicast address, so that each terminal device in terminal group A is added to all multicast addresses in terminal group A. For example, if there are five terminal devices in terminal group A and three multicast addresses are configured, then each terminal device is added to the three multicast addresses with high, medium, and low priorities respectively.

[0038] The above step s01 is performed when there is no broadcast task. Therefore, the delay in calling due to packet loss, network fluctuations, etc. is acceptable. The delay will not delay the broadcast task. Moreover, if there is a situation where the terminal device is unresponsive, the staff can know in time and carry out maintenance before the broadcast task is executed.

[0039] Existing broadcast systems typically employ proprietary control protocols at the TCP application layer. These proprietary protocols usually only interoperate with the developer's own client or system. In contrast, Embodiment 1 of this invention uses SIP protocol commands to construct multicast sessions and control devices within the multicast environment. Since SIP is a mature, standardized protocol in the communications industry that supports multicast signaling, it offers higher interoperability and compatibility. This allows for easy integration with third-party control systems (e.g., access to a group cloud system for broadcast scheduling) and facilitates rapid development and deployment.

[0040] Furthermore, setting multiple multicast addresses with different priorities for each terminal group facilitates the execution of broadcast tasks with different priorities.

[0041] s02. When there is a broadcast task, locate the target terminal group to which the target terminal belongs and select the target multicast address. If the target terminal group has only one multicast address, then that 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. After determining the target multicast address, send an "Exit Multicast" command to the non-target terminals within the target multicast address, and then send a push stream to the target multicast address via the RTP protocol.

[0042] The target terminal refers to the terminal device that needs to perform the broadcast in this broadcast task; the target terminal group refers to the terminal group to which 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 the push stream in this broadcast task.

[0043] For example: Suppose terminal group A is assigned three multicast addresses with high, medium, and low priorities, and there are five terminal devices (denoted as A01-A05) within terminal group A. Now, staff need to send an emergency notification to terminal devices A01, A02, and A05 via a scheduling host. The scheduling host first identifies terminal group A, containing terminals A01, A02, and A05, as the target terminal group. Since emergency notifications are high-priority broadcast tasks, the high-priority multicast address of terminal group A is selected as the target multicast address. Next, the scheduling host identifies non-target terminals A03 and A04 within terminal group A. The scheduling host sends a command to the SIP server to "terminal devices A03 and A04 exit the high-priority multicast of terminal group A." The SIP server then sends a BYE command to terminal devices A03 and A04, containing the target multicast address information. Upon receiving the BYE command, terminal devices A03 and A04 exit the target multicast address. Simultaneously, the scheduling host sends an emergency notification push stream to the high-priority multicast address of terminal group A via the RTP protocol. At this time, terminal devices A01, A02, and A05 will receive the push stream through the target multicast address and complete the broadcast, while terminal devices A03 and A04 have exited the target multicast address, will not receive the push stream, and will not perform the broadcast.

[0044] Sometimes, the target terminals of a broadcast task may be distributed across multiple terminal groups. In this case, step s021 will find two or more target terminal groups. For the scenario where the target terminals of a broadcast task are distributed across multiple target terminal groups, it is only necessary to perform the above s022 operation on each of the multiple target multicast addresses separately. Furthermore, commands for multiple terminal groups can be executed simultaneously without increasing response time. Figure 2As shown, assuming a broadcast task requires the terminal devices A01, A02, and A05 in terminal group A and terminal devices B02 and B03 in terminal group B to perform the broadcast, then the command "Exit high-priority multicast in terminal group A / multicast in terminal group B" is sent to terminal devices A03, A04, B01, and B04 respectively, and then push streams are sent to the target multicast addresses of terminal groups A and B respectively.

[0045] To further improve reliability and avoid misbroadcasting by terminal devices that do not need to broadcast, after sending the "Exit Multicast" command to the non-target terminal in step s022 and simultaneously sending the push stream, the non-target terminal can be required to send back an "Exit Multicast" confirmation upon receiving the command. Specifically, the non-target terminal is required to send back a 200 OK confirmation upon receiving the BYE command to exit the multicast. If the SIP server does not receive the exit multicast confirmation within a timeout period, it will resend the "Exit Multicast" command. If there is still no response after reaching the preset maximum number of resends, the SIP server will send a notification to the scheduling host, and the scheduling host will generate a "Terminal Device Not Responding" report.

[0046] The above-mentioned command of "issuing exit multicast instruction - waiting for confirmation - retransmitting after timeout" is performed synchronously with "sending push stream to target multicast address", thus reducing misbroadcasts to non-target terminals without slowing down the broadcast delivery speed.

[0047] If a non-target terminal fails to receive the "Exit Multicast" command correctly due to packet loss or network fluctuations, a brief misbroadcast may occur. However, upon receiving a subsequent retransmission of the "Exit Multicast" command, the non-target terminal will immediately exit the multicast and stop broadcasting. The misbroadcast duration generally does not exceed one second and will not lead to incorrect transmission of the command. Conversely, if a non-target terminal fails to receive multiple retransmissions of the "Exit Multicast" command, it usually indicates a fault in the terminal device or its branch network. In this case, the terminal device will typically also be unable to receive or broadcast the push stream from the multicast address, and similarly, a prolonged misbroadcast will not occur.

[0048] Sometimes, terminal devices may receive streams from different multicast addresses simultaneously. For example, while broadcasting daily news through a low-priority multicast address, an emergency notification may be broadcast from a high-priority multicast address. In this case, the "high-priority interruption" mechanism should be implemented.

[0049] Therefore, as a preferred solution, when the target terminal performs a broadcast, if it simultaneously receives push streams from multiple target multicast addresses, it prioritizes broadcasting the push stream from the higher-priority target multicast address, interrupts the broadcast of other push streams, and caches the other received push streams in the storage medium of the target terminal device; after the push stream from the higher-priority target multicast address has finished broadcasting, the cached other push streams are then broadcast; if the target terminal receives a unicast call invitation while performing a broadcast, it interrupts the broadcast and caches all push streams, and after the unicast call ends, the cached other push streams are then broadcast.

[0050] Mining broadcast systems typically feature one-to-one unicast SIP calling functionality. After the scheduling host and terminal devices (or two terminal devices) establish a unicast connection via the SIP protocol, they do not send push streams via the RTP protocol but instead directly conduct IP calls. This type of IP call has the lowest latency and is usually used in emergency situations requiring real-time communication. Therefore, the method in Embodiment 1 of this invention is equivalent to setting the unicast call with the highest priority, capable of interrupting all other push streams. Unicast SIP calling is a commonly used technology in existing mining broadcast systems, and its specific implementation will not be elaborated here.

[0051] s03. After the broadcast task is completed, add the non-target terminals of this broadcast task back to the target multicast address. This includes the following steps:

[0052] After the broadcast task is completed, the scheduling host sends a command to the SIP server. The SIP server then sends an INVITE command to the non-target terminals in this broadcast task. The INVITE command contains information such as the target multicast address (i.e., the multicast address that the non-target terminal previously withdrew from) and the transport protocol. 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 does not receive a 200 OK response within a timeout period, it resends the INVITE command to the unresponsive terminal device. If there is still no response after a specified number of resends, the SIP server sends a terminal device no-response report to the scheduling host.

[0053] By utilizing the no-task period after the broadcast task is completed, non-target terminals that previously exited the multicast are re-added to the target multicast address. The call setup delay caused by the aforementioned "terminal device rejoining the multicast" will not delay the broadcast. After joining the multicast, the terminal device can continuously monitor the multicast address. Compared with the original method of "temporarily creating a multicast when a broadcast needs to be sent," the broadcast method of Embodiment 1 of this invention avoids broadcast delays caused by call setup delays, resulting in higher real-time performance; it also avoids missed broadcasts caused by multicast establishment failures, significantly improving the call reception reliability of the terminal device.

[0054] Example 2:

[0055] like Figure 3As shown, Embodiment 2 of the present invention discloses a broadcast system based on SIP and RTP protocols, used to implement the broadcast method based on SIP and RTP protocols disclosed in Embodiment 1 of the present invention. The system includes: a scheduling host, which is a surface control host or a third-party host or control platform connected via a third-party interface; the scheduling host is connected to a SIP server and a core switch; it also includes an underground ring network, with multiple ring network switches forming a ring connection; 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 that can receive and broadcast RTP streams, such as a mine broadcast communication host or a mine broadcast speaker.

[0056] The scheduling host is used to send multicast commands, such as "add specified terminal devices to the multicast" and "remove non-target terminals from the multicast". After receiving the multicast commands, the SIP server implements multicast membership control through SIP protocol commands. At the same time, the SIP server is also used to establish unicast SIP calls between the scheduling host and terminal devices, or between terminal devices.

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

[0058] Finally, it should be noted that the above embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit them. The scope of protection 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 conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention.

Claims

1. A broadcasting method based on SIP and RTP protocols, characterized in that, Includes 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 can receive and broadcast push streams; the broadcast task refers to specifying the terminal device that needs to perform the broadcast through a scheduling host and sending push streams to the specified terminal device; the push stream refers to data packets encapsulated according to the RTP protocol. s02. When there is a broadcast task, find the target terminal group where the target terminal is located, 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 to which the target terminal is located; the non-target terminal refers to the terminal device in the target terminal group that does not perform broadcasting tasks; and the target multicast address refers to the multicast address used to send push streams in the broadcast task. s03. After the broadcast task is completed, add the non-target terminals back to the target multicast address.

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

3. The broadcasting method based on SIP and RTP protocols according to claim 1, characterized in that, In step s02, the selection of the target multicast address specifically includes: if the target terminal group has only one multicast address, then that 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 and RTP protocols according to claim 3, characterized in that, Step s02 also includes: while sending the push stream, requiring non-target terminals 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 timeout period, then resend the exit multicast command; if there is still no response after reaching the preset resend limit, then the scheduling host generates a terminal device no response report.

5. A broadcasting method based on SIP and RTP protocols according to claim 4, characterized in that, Step s02 further includes: when the target terminal performs a broadcast, if it simultaneously receives push streams from multiple target multicast addresses, it prioritizes broadcasting the push stream from the higher-priority target multicast address and interrupts the broadcasting of other push streams, and caches the other received push streams in the storage medium of the target terminal device; after the push stream from the higher-priority target multicast address has finished broadcasting, it broadcasts the other cached push streams; if the target terminal receives a unicast call invitation when performing a broadcast, it interrupts the broadcast and caches all push streams, and after the unicast call ends, it broadcasts the other cached push streams.

6. A broadcast system based on SIP and RTP protocols, characterized in that, The method for implementing a broadcast method based on SIP and RTP protocols as described in claim 1 includes a scheduling host, which is a surface 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; it also includes an underground ring network, in which multiple ring network switches form a ring connection; 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 and RTP protocols 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