Media stream keep-alive method and device, storage medium and media stream transceiver

Abstract

The invention provides a media stream keep-alive method, a media stream keep-alive device, a storage medium and media stream receiving and transmitting equipment. A keep-alive message can be received and transmitted by adopting an RTP (Real-time Transport Protocol). Compared with an RTP over TCP (Transmission Control Protocol), the RTP over UDP (User Datagram Protocol) has higher flexibility, instantaneity and expandability. Meanwhile, according to the receiving time interval of the home terminal device for the first RTP keep-alive message sent by the opposite terminal device, the first response interval of the home terminal device can be dynamically adjusted, and the second RTP keep-alive message is sent to the opposite terminal device, so that the opposite terminal device adjusts the time interval for sending the first RTP keep-alive message according to the first response interval. Therefore, the sending interval of the keep-alive message can be dynamically adjusted according to the network state, so that the network state can be better adapted, the resource waste is reduced, the network utilization rate can be improved, and the efficient transmission of the media stream is realized. Therefore, according to the method and the device, efficient transmission can be realized, and the security privacy of the transmission process can be ensured.

Description

Technical Field

[0001] The present application relates to the field of security monitoring technology, and in particular to a media stream keep-alive method, device, storage medium, and media stream transceiver. Background Art

[0002] In the field of video surveillance, how to achieve efficient and stable transmission of media streams is one of the technical focuses. With the large-scale promotion of the GB28181 standard, media streams are mostly transmitted using the unreliable network transport layer protocol UDP. Although the GB28181 standard stipulates a media stream keep-alive mechanism to improve the transmission reliability of media streams, this mechanism only considers various registration states and heartbeat states at the signaling level, which deviates from the situation where the sender and receiver need to directly participate in the actual media stream transmission process. At the same time, since the device or platform is usually mounted with multiple video surveillance devices, and the status of a single device cannot cover multiple video surveillance devices and monitor the transmission status of multiple media streams, the existing technology cannot control multiple video surveillance devices one by one. Due to the lack of an effective media stream keep-alive mechanism, the existing technology often has abnormal phenomena such as streaming and wild streaming during media stream transmission, which greatly reduces the stability and availability of the video surveillance system.

[0003] In order to solve the above-mentioned problem of out-of-control media stream transmission, the prior art proposes to use standard RTCP for flow control while using RTP for media stream transmission. However, the technology of standard RTCP is relatively cumbersome and will increase the number of network ports used exponentially. This does not meet the actual demand of reducing the number of ports used. Therefore, standard RTCP technology is difficult to promote and apply in practical applications. In addition, the prior art also proposes a method of using TCP for media stream keep-alive transmission. However, this method requires a large amount of network resources to be occupied and consumed, cannot achieve efficient transmission of media streams, and cannot guarantee the privacy and security of media stream data.

[0004] It can be seen that the existing media stream keep-alive methods cannot take into account both efficiency and security and privacy. Summary of the invention

[0005] The purpose of this application is to solve at least one of the above-mentioned technical defects, especially the technical defect that the prior art cannot balance efficiency and security and privacy.

[0006] In a first aspect, an embodiment of the present application provides a media stream keep-alive method, which is applied to a first media device configured with a first response interval, wherein the first media device is any media stream transceiver device in a media stream transmission system; the method includes:

[0007] When receiving a first RTP keep-alive message sent by a second media device, performing a keep-alive check on the first RTP keep-alive message; wherein the second media device is a media stream transceiver device in the media stream transmission system that performs media stream transceiver interaction with the first media device;

[0008] When the keep-alive check passes, the message receiving interval is calculated according to the latest receiving time and the previous receiving time of the first RTP keep-alive message, and the upper limit threshold and the lower limit threshold are determined respectively;

[0009] If the message receiving interval is greater than the upper threshold, lowering the first response interval;

[0010] If the message receiving interval is less than the lower limit threshold, increasing the first response interval;

[0011] In response to satisfying the triggering rule for sending the keep-alive message, a second RTP keep-alive message is generated according to the first response interval, and the second RTP keep-alive message is sent to the second media device, so that the second media device sends the first RTP keep-alive message to the first media device periodically according to the first response interval.

[0012] In some embodiments, the determining the upper threshold and the lower threshold respectively includes:

[0013] According to the message receiving interval and the preset smoothing factor, updating the interval average value;

[0014] The product of the interval average value and the network variation coefficient is used as the upper limit threshold; wherein the network variation coefficient is a pre-set coefficient greater than 1;

[0015] The ratio of the interval average value to the network variation coefficient is used as the lower limit threshold.

[0016] In some embodiments, the method further comprises:

[0017] Determine a loss of connection determination interval according to the first response interval;

[0018] If the first RTP keep-alive message is not received within the disconnection determination interval, it is determined that the second media device is disconnected;

[0019] When it is determined that the second media device is disconnected or fails the keep-alive check, the connection between the first media device and the second media device is disconnected, and resources are released.

[0020] In some embodiments, performing keep-alive verification on the first RTP keep-alive message includes:

[0021] Extracting a first device identifier and a first network connection information from the first RTP message respectively; wherein the first device identifier is a device identifier of a video acquisition device involved in the current media stream transceiving interaction of the second media device, and the first network connection information is network connection information involved in the current media stream transceiving interaction of the second media device;

[0022] If the first RTP keep-alive message is the first keep-alive message received by the first media device in this media stream transceiver interaction, the first device identifier is compared and verified with a pre-acquired target device identifier, and if the comparison and verification pass, the first network connection information is saved as the target network connection information;

[0023] If the first RTP keep-alive message is not the first keep-alive message received by the first media device in this media stream transceiver interaction, the first device identifier and the target device identifier are compared and verified, and the first network connection information and the target network connection information are compared and verified.

[0024] In some embodiments, generating a second RTP keep-alive message according to the first response interval includes:

[0025] Obtain a second device identifier and a second network connection information; wherein the second device identifier is a device identifier of a video acquisition device involved in the current media stream transceiving interaction of the first media device, and the second network connection information is network connection information involved in the current media stream transceiving interaction of the first media device;

[0026] The second RTP keep-alive message is generated according to the first response interval, the second device identifier and the second network connection information, so that the extended header information of the second RTP keep-alive message carries the first response interval, the second device identifier and the second network connection information.

[0027] In some embodiments, the first network connection information includes the network address of the second media device, the port information corresponding to the second media device in the current media stream transceiver interaction, and the SSRC corresponding to the second media device;

[0028] The second network connection information includes the network address of the first media device, the port information corresponding to the first media device in the current media stream sending and receiving interaction, and the SSRC corresponding to the first media device.

[0029] In some of the embodiments, the triggering rule for sending the keep-alive message is to determine whether a message sending period has arrived, and the message sending period is determined according to a second response interval carried by the first RTP keep-alive message.

[0030] In a second aspect, an embodiment of the present application provides a media stream keep-alive device, which is applied to a first media device configured with a first response interval, wherein the first media device is any media stream transceiver device in a media stream transmission system; the device includes:

[0031] A keep-alive verification module, configured to perform a keep-alive verification on a first RTP keep-alive message sent by a second media device when the first RTP keep-alive message is received; wherein the second media device is a media stream transceiver device in the media stream transmission system that performs media stream transceiver interaction with the first media device;

[0032] A receiving interval calculation module, used to calculate the message receiving interval according to the latest receiving time and the previous receiving time of the first RTP keep-alive message when the keep-alive check passes, and determine the upper limit threshold and the lower limit threshold respectively;

[0033] A first adjustment module, configured to lower the first response interval if the message receiving interval is greater than the upper threshold;

[0034] A second adjustment module, configured to increase the first response interval if the message receiving interval is less than the lower limit threshold;

[0035] A keep-alive message sending module is used to generate a second RTP keep-alive message according to the first response interval in response to meeting the keep-alive message sending trigger rule, and send the second RTP keep-alive message to the second media device, so that the second media device sends the first RTP keep-alive message to the first media device regularly according to the first response interval.

[0036] In a third aspect, an embodiment of the present application provides a storage medium storing computer-readable instructions. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the media stream keep-alive method described in any of the above embodiments.

[0037] In a fourth aspect, an embodiment of the present application provides a media stream transceiver device, the media stream transceiver device comprising: one or more processors, and a memory;

[0038] The memory stores computer-readable instructions, and when the computer-readable instructions are executed by the one or more processors, the steps of the media stream keep-alive method described in any one of the above embodiments are executed.

[0039] In the media stream keep-alive method, device, storage medium and media stream transceiver provided in some embodiments of the present application, the RTP protocol can be used to send and receive keep-alive messages. Compared with the RTP over TCP protocol, the RTP over UDP protocol has higher flexibility, real-time and scalability. At the same time, the present application can dynamically adjust the first response interval of the present device according to the reception time interval of the first RTP keep-alive message sent by the opposite device by the present device, and send the second RTP keep-alive message to the opposite device, so that the opposite device adjusts the time interval for sending the first RTP keep-alive message according to the first response interval. In this way, the sending interval of the keep-alive message can be dynamically adjusted according to the network status, so as to better adapt to the network status and reduce resource waste, thereby improving network utilization and realizing efficient transmission of media streams. It can be seen that the present application can not only realize efficient transmission, but also ensure the security and privacy of the transmission process. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0041] Figure 1 is a schematic diagram of the architecture of a media stream transmission system in one embodiment;

[0042] Figure 2 It is one of the flowcharts of the media stream keep-alive method in one embodiment;

[0043] Figure 3 The second flowchart of the media stream keep-alive method in one embodiment is shown;

[0044] Figure 4 In one embodiment, the message header format of the RTP keep-alive message;

[0045] Figure 5 is a schematic structural diagram of a media stream keep-alive device in one embodiment;

[0046] Figure 6 FIG. 4 is an internal structure diagram of a media stream transceiver device in one embodiment. DETAILED DESCRIPTION

[0047] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0048] The terms involved in this application are explained below.

[0049] UDP (User Datagram Protocol): A connectionless transport layer protocol.

[0050] RTP (Real-time Transport Protocol): A network transmission protocol used to transmit audio, video or other real-time data.

[0051] RTCP (RTP Control Protocol): A protocol used to monitor the quality of RTP transmission and control the sending rate of RTP streams.

[0052] TCP (Transmission Control Protocol): a connection-oriented, reliable, byte-stream-based transport layer communication protocol.

[0053] IP (Internet Protocol): Network layer protocol in the TCP / IP system.

[0054] Media stream keep-alive mechanism: A series of measures taken to ensure that the media stream can maintain stable transmission in an unreliable network environment, usually including periodic status reports, heartbeat signals, etc., to detect and / or recover from possible transmission interruptions.

[0055] Cross-streaming: refers to the situation where media stream data is not correctly directed to the intended recipient, but is mistakenly captured by another recipient.

[0056] Wild flow: refers to the situation where media stream data is transmitted on a path that should not exist, usually caused by network configuration errors or equipment failures.

[0057] SSRC (Synchronization Source Identifier): A 32-bit integer used in RTP messages to uniquely identify the source of the media stream.

[0058] Smoothing factor: A coefficient used in the algorithm to smooth data changes. Smoothing can reduce the impact of noise and make the calculation results more stable.

[0059] In some embodiments, the media stream keep-alive method provided in this application can be applied to Figure 1 In the media streaming transmission system shown in FIG. 1 , the media streaming transmission system may include a video acquisition device, a streaming media server, a central scheduling server, an access unit, and an electronic terminal. The electronic terminal may be installed with a client program for viewing the surveillance video acquired by the video acquisition device through the client program.

[0060] Users can initiate video playback requests through the client program, and the streaming media server pulls the RTP media stream from the video capture device, and then the streaming media server pushes the video media stream to the client program, ultimately achieving real-time video playback.

[0061] Specifically, see Figure 2 , the user can initiate a video playback request through the client program installed in the electronic terminal, so that the client program sends a video push request to the central scheduling server. In response to the video push request, the central scheduling server sends a signal to the video acquisition device, the streaming media server, the access unit and the electronic terminal. Figure 2 In the description, "extended media message" refers to the RTP keepalive message sent by the media stream sender, and "keepalive message" refers to the RTP keepalive message sent by the media stream receiver.

[0062] Furthermore, in some examples, the signaling sent by the central scheduling server to the streaming media server carries key information such as the device code to which the RTP media stream to be pulled belongs, the network address of the video acquisition device, the media stream push port of the streaming media server, the address of the client program decoding plug-in, and the media stream receiving port of the client. The signaling sent by the central scheduling server to the client program may carry the network address of the streaming media server, the media stream push port of the streaming media server, and the device code to which the RTP media stream to be pulled belongs. Among them, the device code to which the RTP media stream to be pulled belongs refers to the device code corresponding to the video acquisition device used to collect the surveillance video to be pulled. For example, when the surveillance video to be pulled is collected by the first video acquisition device, the device code of the first video acquisition device is the device code to which the RTP media stream to be pulled mentioned above belongs.

[0063] After receiving the signaling request forwarded by the central scheduling server, the access unit can carry the session description protocol SDP to send a video request to the video acquisition device, so that a session can be established between the streaming media server and the video acquisition device and media streams can be sent and received based on the established session. In addition, the access unit can also establish a session between the streaming media server and the electronic terminal, so that the streaming media server and the electronic terminal can send and receive media streams based on the established session.

[0064] Specifically, the streaming media server may pull the RTP video media stream (i.e., the media stream of the surveillance video) from the video acquisition device. The video acquisition device may send the RTP video media stream to the streaming media server, and may also send an RTP keep-alive message to the streaming media server at intervals. In one example, the RTP keep-alive message may have extended header information, and the extended header information may carry keep-alive information, and the keep-alive information includes the device code, the network address of the video acquisition device, the media stream push port of the video acquisition device, and the SSRC corresponding to the video acquisition device.

[0065] When the streaming media server receives the RTP keep-alive message sent by the video acquisition device, it can extract the device code from the RTP keep-alive message and compare the device code extracted from the RTP keep-alive message with the device code obtained by the device during signaling interaction. If the two device codes are inconsistent, it is determined that an abnormality has occurred, and the streaming media server sends an abnormality report information to the central scheduling server. The central scheduling server forwards the abnormality report information to the access unit to instruct the access unit to stop the target task. The target task refers to the media stream receiving and sending task related to the device code carried by the RTP keep-alive message.

[0066] If the codes of the two devices are consistent, the streaming media server may include the keep-alive information in the RTP keep-alive message, including the network address of the video capture device, the media stream push port of the video capture device, and the SSRC corresponding to the video capture device. The streaming media server may compare the device code and the saved keep-alive information obtained from the signaling interaction with the RTP streaming media message subsequently received and sent by the video capture device. If the network address, port, SSRC or device code of the subsequent RTP message changes, it indicates that the message is not the media stream sent by the device of the current task, and the message is an abnormal media stream, so this part of the message can be filtered.

[0067] If the network address, port, SSRC and device code of the subsequent RTP message are consistent with the saved information, the streaming media server can determine that the keep-alive check has passed. After receiving the normal media stream sent by the video capture device, the streaming media server can send RTP keep-alive messages to the client program at intervals (for example, every 5 seconds).

[0068] In an example, the RTP keep-alive message may have extended header information, which may carry keep-alive information including device code, network address of the streaming media server, media stream push port of the streaming media server, and SSRC corresponding to the streaming media server.

[0069] When receiving the RTP keep-alive message sent by the streaming media server, the client program can perform a keep-alive check on the RTP keep-alive message sent by the streaming media server according to the keep-alive check process of the streaming media server for the RTP keep-alive message sent by the video acquisition device.

[0070] When the keep-alive check passes, the client program can receive the normal media stream sent by the streaming media server, and can send an RTP keep-alive message to the streaming media server at intervals (for example, every 5 seconds). In one example, the RTP keep-alive message can have extended header information, and the extended header information can carry keep-alive information, which includes the device code, the network address of the client program (i.e., the electronic terminal), the media stream receiving port of the client program, and the SSRC corresponding to the client program.

[0071] Similarly, the streaming media server may also send an RTP keep-alive message to the video capture device at intervals (e.g., every 5 seconds) so that the video capture device can perform a keep-alive check on the streaming media server. In one example, the RTP keep-alive message may have extended header information, which may carry keep-alive information including the device code, the network address of the streaming media server, the media stream receiving port of the media server, and the SSRC corresponding to the streaming media server.

[0072] For each of the three devices, namely, the video acquisition device, the streaming media server and the electronic terminal, the local device can receive the RTP keep-alive message sent by the opposite device, and calculate the receiving time interval between two adjacent RTP keep-alive messages according to the receiving timestamp of each RTP keep-alive message. The local device can dynamically adjust its expected receiving interval (i.e., response interval) for the opposite RTP keep-alive message according to the corresponding receiving time interval of the opposite device, and put the response interval into the RTP keep-alive message sent by the local device, so as to send the corresponding response interval of the local device to the opposite device through the RTP keep-alive message.

[0073] The local device can determine whether the peer device is disconnected based on the expected receiving interval P corresponding to the local device. For example, if the local device does not receive the RTP keep-alive message sent by the peer device in N consecutive Ps, it can be determined that the peer device is disconnected. Wherein, N can be a preset positive integer, such as N=3.

[0074] When it is determined that the peer device is disconnected, the local device can report to the central scheduling server to request to disconnect the connection, and release its own resources related to the task, and no longer push and / or receive related video streams. In one example, when it is determined that the peer device is disconnected, the local device can send a disconnect request to the central scheduling server. After receiving the disconnect request, the central scheduling server requests the access unit to forward the media stream disconnect signaling so that the device releases media resources.

[0075] It should be noted that in this solution, the local device can send RTP keep-alive messages to the remote device at regular intervals, and the remote device can send RTP keep-alive messages to the local device at regular intervals. Since the network conditions seen by both parties in the UDP protocol are different, the process of calculating the response interval between the local device and the remote device does not affect each other.

[0076] In other words, for the local device, whether the opposite device sends an RTP keep-alive message does not affect the local device's delivery of the RTP keep-alive message to the opposite device. After receiving the RTP keep-alive message sent by the opposite device, the response interval P2 parsed from the message affects the time interval for the local device to send the RTP keep-alive message next time, but does not participate in the calculation of the local device's response interval P1.

[0077] In one example, the response intervals P1 and P2 may be initialized to P0 in the initial state to prevent P1 and P2 from being empty. As the media stream transmission and reception process proceeds, the local device may subsequently adjust P1 according to the arrival time of the RTP keep-alive message sent by the opposite device, and the opposite device may subsequently adjust P2 according to the arrival time of the RTP keep-alive message sent by the local device.

[0078] It can be understood that the local device and the opposite device can be determined based on the execution device and the interacting parties involved in the keep-alive message. For example, when the execution device is a streaming media server, in the scenario where the streaming media server sends an RTP keep-alive message to the video acquisition device, and in the scenario where the streaming media server receives the RTP keep-alive message sent by the video acquisition device, the local device is the streaming media server and the opposite device is the video acquisition device. When the execution device is a streaming media server, in the scenario where the streaming media server sends an RTP keep-alive message to the client program, and in the scenario where the streaming media server receives the RTP keep-alive message sent by the client program, the local device is the streaming media server and the opposite device is the electronic terminal.

[0079] When the execution device is a video capture device, in the scenario where the video capture device sends an RTP keep-alive message to a streaming media server, and in the scenario where the video capture device receives an RTP keep-alive message sent by a streaming media server, the local device is the video capture device, and the opposite device is the streaming media server. When the execution device is an electronic terminal, in the scenario where the electronic terminal sends an RTP keep-alive message to a streaming media server, and in the scenario where the electronic terminal receives an RTP keep-alive message sent by a streaming media server, the local device is the electronic terminal, and the opposite device is the streaming media server.

[0080] In the RTP media stream transmission process provided in this embodiment, an extended field for detecting the media stream transmission status is added to the RTP keep-alive message, thereby ensuring that the sender and receiver can accurately perceive the transmission status of the other end and ensure the authenticity and effectiveness of the media stream transmission. Compared with the traditional keep-alive method, the media stream keep-alive solution provided by this application does not require a separate channel, reducing bandwidth and port exposure. At the same time, this application dynamically adjusts the response interval of the device so that the sending of keep-alive messages can better adapt to the network conditions, which not only avoids resource waste but also improves network utilization.

[0081] At the same time, by periodically adding extended fields during the RTP media stream transmission process of the media stream transmission system, only the address information, device code and response interval control field of the two parties in the media stream interaction are used, so that the sender and receiver of the media stream can perceive the real-time status of the other party's media stream transmission to ensure the normal progress of the media stream transmission process, and can make timely and effective recovery processing when an abnormality occurs, to ensure the authenticity and effectiveness of the media stream transmission, to avoid the situation where the sender of the media stream has stopped sending the stream, but the receiver is still waiting to receive and occupying system resources, or the media stream receiver has stopped receiving, but the sender continues to send, resulting in streaming or wild streaming, resulting in waste and exhaustion of resources such as bandwidth, thereby improving the stability and availability of the video surveillance system and reducing the port exposure of the video surveillance platform.

[0082] The media stream keep-alive method provided by this application is described in detail below.

[0083] In some embodiments, the present application provides a media stream keep-alive method, and the following embodiments are described by taking the method applied to a first media device as an example. The first media device and the second media device perform media stream transceiving interaction. In some examples, the first media device and the second media device can perform media stream transceiving interaction based on the RTP protocol.

[0084] The first media device refers to any media stream transceiver device in the media stream transmission system, that is, the first media device can be any media stream transceiver device in the media stream transmission system. The second media device refers to any media device in the media stream transmission system except the first media device.

[0085] It should be noted that the first media device may be a media stream sender, and the second media device may be a media stream receiver. Alternatively, the first media device may be a media stream receiver, and the second media device may be a media stream sender. This document does not impose specific restrictions on this.

[0086] For example, in Figure 1 In the media stream transmission system shown, the first media device may be a video acquisition device, a streaming media server or an electronic terminal. When the first media device is a video acquisition device, the second media device may be a streaming media server. When the first media device is a streaming media server, the second media device may be a video acquisition device or an electronic terminal. When the first media device is an electronic terminal. The second media device may be a streaming media server.

[0087] The first media device is configured with a first response interval, which refers to the expected time interval for the first media device to send a first RTP keep-alive message to the second media device. For example, when the first response interval is P1, the first media device expects the second media device to send the first RTP keep-alive message according to P1.

[0088] like Figure 3 The media stream keep-alive method provided in this application may include the following steps:

[0089] S302: When receiving a first RTP keep-alive message sent by the second media device, perform a keep-alive check on the first RTP keep-alive message.

[0090] The second media device is a media stream transceiver device that performs media stream transceiver interaction with the first media device in the media stream transmission system. The first RTP keep-alive message refers to a keep-alive message based on the RTP protocol sent by the second media device.

[0091] In this step, when the first media device receives the first RTP keep-alive message, it can perform a keep-alive check based on the information carried by the first RTP keep-alive message and / or preset verification rules to determine whether the media stream transmission channel between the first media device and the second media device is normal and whether any abnormal situation occurs during the transmission process.

[0092] S304: When the keep-alive check passes, the message receiving interval is calculated according to the latest receiving time and the previous receiving time of the first RTP keep-alive message, and the upper and lower thresholds are determined respectively.

[0093] Among them, the latest reception time refers to the time when the first media device last received the first RTP keep-alive message, and the previous reception time refers to the time when the first media device previously received the first RTP keep-alive message. For example, if the first media device receives the first RTP message at times t1, t2, and t3 respectively, where t1 < t2 < t3, and the current time is t3, then the latest reception time is t3, and the previous reception time is t2.

[0094] In this step, in response to receiving the first RTP message, the first media device can calculate the message reception interval based on the latest reception time and the previous reception time, and respectively determine the upper threshold and the lower threshold. In one example, the message reception interval . Among them, is the timestamp corresponding to the latest reception time, is the timestamp corresponding to the previous reception time. In another example, the upper threshold and the lower threshold can be obtained by pre-setting.

[0095] It should be noted that in the case of receiving each first RTP keep-alive message, the first media device will re-perform the keep-alive check, and re-determine the message reception interval, the upper threshold, and the lower threshold during the keep-alive check.

[0096] For example, if the first media device receives the first RTP message at times t1, t2, and t3 respectively, then when the first media device receives the first RTP keep-alive message at time t1, it will calculate the message reception interval corresponding to this message and respectively determine the upper threshold and the lower threshold; when receiving the first RTP keep-alive message at time t2, the first media device will re-calculate the message reception interval corresponding to this message based on times t1 and t2, and respectively determine the upper threshold and the lower threshold. When receiving the first RTP keep-alive message at time t3, the first media device will re-calculate the message reception interval corresponding to this message based on times t2 and t3, and respectively determine the upper threshold and the lower threshold.

[0097] S306: If the message reception interval is greater than the upper threshold, then lower the first response interval.

[0098] In this step, the first media device can compare the message reception interval with the upper threshold, and adjust the first response interval configured in the first media device according to the size relationship between the message reception interval and the upper threshold. Specifically, if the message reception interval is greater than the upper threshold, it indicates that the second media device has too long a sending interval for the first RTP keep-alive message, or there is a possibility of message loss in the first RTP keep-alive message. Therefore, the first media device can lower the first response interval to more accurately detect the situation of the media stream transmission channel.

[0099] S308: If the message receiving interval is less than the lower limit threshold, increase the first response interval.

[0100] In this step, the first media device may compare the message receiving interval with the lower threshold, and adjust the first response interval according to the relationship between the message receiving interval and the lower threshold. Specifically, if the message receiving interval is less than the lower threshold, it indicates that the network status between the first media device and the second media device is good, so the first response interval may be increased to reduce the network resources occupied by the media stream keep alive, and more network resources may be used to transmit media stream data (such as video data).

[0101] S310: In response to satisfying the triggering rule for sending the keep-alive message, generate a second RTP keep-alive message according to the first response interval, and send the second RTP keep-alive message to the second media device, so that the second media device sends the first RTP keep-alive message to the first media device regularly according to the first response interval.

[0102] The trigger rule for sending the keep-alive message refers to a rule for determining whether the first media device needs to send the second RTP keep-alive message to the second media device. The content of the rule can be determined according to actual conditions, and this document does not impose any specific restrictions on this.

[0103] In one example, the first RTP keep-alive message may carry a second response interval, and the second response interval refers to the expected time interval for the second media device to send the second RTP keep-alive message to the first media device. The first media device may determine the message sending period according to the second response interval, and determine whether the message sending period has arrived to determine whether the sending trigger rule of the keep-alive message is met. When the message sending period arrives, the first media device may determine that the sending trigger rule of the keep-alive message is met. In this way, the first media device may periodically send the second RTP keep-alive message according to the second response interval.

[0104] When the triggering rules for sending keep-alive messages are met, the first media device can generate a second RTP keep-alive message according to the first response interval, and send the second RTP keep-alive message to the second media device to instruct the second media device to send the first RTP keep-alive message to the first media device periodically according to the first response interval.

[0105] In the present application, the RTP protocol can be used to send and receive keep-alive messages. Compared with the RTP over TCP protocol, the RTP over UDP protocol has higher flexibility, real-time and scalability. At the same time, the present application can dynamically adjust the first response interval of the present device according to the reception time interval of the first RTP keep-alive message sent by the opposite device by the present device, and send a second RTP keep-alive message to the opposite device, so that the opposite device adjusts the time interval for sending the first RTP keep-alive message according to the first response interval. In this way, the sending interval of the keep-alive message can be dynamically adjusted according to the network status, so as to better adapt to the network status and reduce resource waste, thereby improving network utilization and realizing efficient transmission of media streams. It can be seen that the present application can not only realize efficient transmission, but also ensure the security and privacy of the transmission process.

[0106] In some embodiments, the steps of respectively determining the upper threshold and the lower threshold include:

[0107] Step A1: updating the interval average value according to the message receiving interval and the preset smoothing factor;

[0108] Step A2: taking the product of the interval average value and the network variation coefficient as the upper threshold; wherein the network variation coefficient is a pre-set coefficient greater than 1;

[0109] Step A3: The ratio between the interval average and the network variation coefficient is used as the lower threshold.

[0110] In this embodiment, in order to reduce the impact of noise, this embodiment can update the interval average value according to the preset smoothing factor and the message receiving interval; and determine the upper threshold and the lower threshold based on the updated interval average value.

[0111] In one example, the first media device may To update the interval average value. is the updated interval average, is the preset smoothing factor, Can be between 0 and 1, is the message receiving interval, is the interval average before updating.

[0112] Understandably, The value of can be adjusted and The weight of the network can be determined in advance based on the actual situation. For example, in order to quickly respond to network changes, A smaller value (for example, between 0.1 and 0.3) can be used to quickly respond to network changes.

[0113] To facilitate the evaluation of the network situation, the first media device may calculate the upper threshold and the lower threshold respectively according to the updated interval average value and the preset network change coefficient. Specifically, the upper threshold may be , the lower threshold can be , is the network variation coefficient.

[0114] Understandably, It can be used to reflect network changes. For example, when the network is relatively stable, A larger value can be selected to reduce the possibility of misjudgment. You can choose a smaller value to respond faster to network changes. In one example, A value of 1.2 to 1.5 can be selected to quickly respond to network changes.

[0115] In one example, the first response interval P may be adjusted according to the following expression:

[0116]

[0117] in, is an adjustment factor between 0 and 1.

[0118] when When , it indicates that the current network status of the first media device and the second media device is congested or blocked, so the first response interval can be appropriately reduced to improve network utilization. , it indicates that the current network status is smooth, so the first response interval can be appropriately increased.

[0119] Furthermore, considering the larger A large value will cause the first response interval to be adjusted more, which may cause system instability in extreme cases; while a smaller value A value of will result in smaller adjustments to the first response interval, which can make the system more stable but less responsive. It is more stable to select around 0.3.

[0120] In some embodiments, the media stream keep-alive method may further include the following steps:

[0121] Step B1: determining a loss of connection determination interval according to the first response interval;

[0122] Step B2: If the first RTP keep-alive message is not received within the disconnection determination interval, it is determined that the second media device is disconnected;

[0123] Step B3: When it is determined that the second media device is disconnected or the keep-alive check fails, disconnect the first media device from the second media device and release resources.

[0124] In this embodiment, the first media device may determine the disconnection determination interval T according to the first response interval P. In one example, the first media device may be pre-set with a maximum tolerance number N, and the disconnection determination interval T may be N×P.

[0125] The first media device can determine whether the first RTP keep-alive message has not been received for a long time according to the loss of connection determination interval. If the first RTP keep-alive message is not received within the loss of connection determination interval, the first media device can directly determine that the second media device is lost, and can disconnect and release media resources. When the most recently received first RTP keep-alive message fails the keep-alive check, the first media device can disconnect and release media resources. For example, when T=10s, if the first media device does not receive the first RTP keep-alive message for 10 consecutive seconds, it can be determined that the second media device is lost.

[0126] It can be understood that, when the first RTP keep-alive message is not received, the first media device may keep the first response interval and the second response interval unchanged, and send the second RTP keep-alive message to the second media device according to the second response interval.

[0127] In some embodiments, performing a keep-alive check on the first RTP keep-alive message includes:

[0128] Step C1: extracting the first device identifier and the first network connection information from the first RTP message respectively; wherein the first device identifier is the device identifier of the video acquisition device involved in the current media stream transceiving interaction of the second media device, and the first network connection information is the network connection information involved in the current media stream transceiving interaction of the second media device;

[0129] Step C2: if the first RTP keep-alive message is the first keep-alive message received by the first media device in this media stream transceiver interaction, the first device identifier is compared and verified with the pre-acquired target device identifier, and if the comparison and verification pass, the first network connection information is saved as the target network connection information;

[0130] Step C3: If the first RTP keep-alive message is not the first keep-alive message received by the first media device in this media stream transceiver interaction, the first device identifier is compared and verified with the target device identifier, and the first network connection information is compared and verified with the target network connection information.

[0131] In this embodiment, a keep-alive check can be performed based on the device identification and network connection information, thereby improving the reliability of the keep-alive check, and further increasing the sensitivity of the media stream transmission process, ensuring that the video stream is transmitted under reliable and accurate technical conditions, and solving various situations where the media stream transmission is out of control.

[0132] If the media stream data involved in the media stream transceiving interaction between the first media device and the second media device is the first media stream data, the first device identifier may be the national standard device code of the video acquisition device used to acquire the first media stream data. The target device identifier may be the device identifier of the video acquisition device pre-acquired by the first media device. In one example, the target device identifier may be obtained during the signaling interaction between the first media device and the central scheduling server.

[0133] The first network connection information may be the network connection information involved in the current media stream transceiving interaction of the second media device. In one example, the first network connection information includes the network address of the second media device, the port information corresponding to the current media stream transceiving interaction of the second media device, and the SSRC corresponding to the second media device.

[0134] In the process of performing keep-alive verification on the first RTP keep-alive message, the first media device can first extract the first device identifier and the first network connection information from the received first RTP keep-alive message, and compare these key fields with the information obtained during the signaling interaction to determine whether the two are consistent. If there is a deviation in the key field, the media stream protection mechanism can be triggered, and the media stream receiver and the media stream sender can take corresponding actions according to the roles they assume, increase the sensitivity of the media stream transmission process, ensure that the video stream is transmitted under reliable and accurate technical conditions, and solve various situations where the media stream transmission is out of control.

[0135] Specifically, the first media device can determine whether the first RTP keep-alive message received this time is the first keep-alive message received by the first media device in this media stream sending and receiving interaction. If so, the first device identifier carried by the first RTP keep-alive message can be compared and verified with the target device identifier pre-acquired by the first media device to determine whether the two are consistent. In the case where the first device identifier and the target device identifier are the same, it can be determined that the comparison and verification are passed, and the first media device can save the first network connection information as the target network connection information, so as to facilitate the keep-alive verification of the first RTP keep-alive message received subsequently according to the target network connection information.

[0136] If the first RTP keep-alive message received this time is not the first keep-alive message received by the first media device in this media stream transceiver interaction, the first media device may perform a keep-alive check based on the first device identifier and the first network connection information. Specifically, the first media device may compare the first device identifier with the target device identifier, and compare the first network connection information with the saved target network connection information. If the first device identifier is the same as the target device identifier, and the first network connection information is the same as the target network connection information, it can be determined that the keep-alive check has passed. Otherwise, it can be determined that the keep-alive check has failed.

[0137] Further, in one example, if the keep-alive check passes, the first media device may continue to receive the device code stream. If the keep-alive check fails, the first media device may stop the current task.

[0138] In another example, if the first media device is a media stream receiver, the first media device receives the RTP media message after starting the video task, and does not process any media stream data before confirming the arrival of the first RTP keep-alive message.

[0139] In some embodiments, generating a second RTP keep-alive message according to the first response interval includes:

[0140] Obtain a second device identifier and second network connection information; wherein the second device identifier is a device identifier of a video acquisition device involved in the current media stream transceiving interaction of the first media device, and the second network connection information is network connection information involved in the current media stream transceiving interaction of the first media device;

[0141] A second RTP keep-alive message is generated according to the first response interval, the second device identifier and the second network connection information, so that the extended header information of the second RTP keep-alive message carries the first response interval, the second device identifier and the second network connection information.

[0142] If the media stream data involved in the current media stream receiving and sending interaction between the first media device and the second media device is the first media stream data, the second device identifier may be the national standard device code of the video acquisition device used to acquire the first media stream data.

[0143] The second network connection information may be the network connection information involved in the current media stream transceiving interaction of the first media device. In one example, the second network connection information includes the network address of the first media device, the port information corresponding to the current media stream transceiving interaction of the first media device, and the SSRC corresponding to the first media device.

[0144] Specifically, the present application can extend the RTP protocol header, and directly add information such as the second device identifier, the second network connection information, and the first response interval to the extended field of the RTP protocol header to form a new RTP message (i.e., the second RTP keep-alive message). The second RTP keep-alive message can be directly transmitted on the media stream transmission port. For the media stream recipient, it can verify the received RTP message while performing the media stream receiving task on the receiving port of the RTP media stream. If the RTP message of the media stream sender is identified as an extended message, its content is parsed. In this way, there is no need to occupy additional port resources, thereby saving the use of port resources. In addition, the RTP keep-alive message and the real RTP media stream message can be distinguished by the extended flag bit allowed by the RTP protocol, so as not to affect the encapsulation and transmission format of the original media stream.

[0145] In an example, the header format of the second keep-alive message may be as follows: Figure 4 As shown, ExtensionID is the extension identifier, ExtensionID is the extension length, Port Number is the port information of the first media device used for the media stream sending and receiving interaction, IP Address is the IP address of the first media device, DeviceID is the second device identifier, DynamicTimestamp is the timestamp corresponding to the first response interval, and the remaining fields can be the native fields of the RTP protocol header.

[0146] In another example, if the first media device is a media stream sender, the first message transmitted by the first media stream device in this media stream transceiver interaction may be a second RTP keep-alive message to monitor the transmission status of the media stream receiver before formally transmitting the media stream data.

[0147] In the present application, a method for periodically adding extended fields during the RTP media stream transmission process of the media stream transmission system is provided. This method only uses the address information, device code and response interval control field of the two parties in the media stream interaction, so that the sender and receiver of the media stream can ensure the normal progress of the media stream transmission process by perceiving the real-time status of the other party's media stream transmission, and can make timely and effective recovery processing when an abnormality occurs, thereby ensuring the authenticity and effectiveness of the media stream transmission, avoiding the situation where the sender of the media stream has stopped sending the stream, while the receiver continues to wait for receiving and occupies system resources, or the receiver of the media stream has stopped receiving, while the sender continues to send, resulting in streaming or wild streaming, resulting in waste and exhaustion of resources such as bandwidth, improving the stability and availability of the video surveillance system, and reducing the port exposure of the video surveillance platform.

[0148] The following describes a media stream keep-alive device provided in an embodiment of the present application. The media stream keep-alive device described below and the media stream keep-alive method described above can refer to each other.

[0149] In some embodiments, the present application provides a media stream keep-alive device, which is applied to a first media device configured with a first response interval, wherein the first media device is any media stream transceiver device in a media stream transmission system. Figure 5 As shown, the media stream keep-alive device 500 includes:

[0150] A keep-alive check module 502 is used to perform a keep-alive check on a first RTP keep-alive message sent by a second media device when the first RTP keep-alive message is received; wherein the second media device is a media stream transceiver device in the media stream transmission system that performs media stream transceiver interaction with the first media device;

[0151] A receiving interval calculation module 504 is used to calculate the message receiving interval according to the latest receiving time and the previous receiving time of the first RTP keep-alive message when the keep-alive check passes, and determine the upper limit threshold and the lower limit threshold respectively;

[0152] A first adjustment module 506, configured to lower the first response interval if the message receiving interval is greater than the upper threshold;

[0153] A second adjustment module 508, configured to increase the first response interval if the message receiving interval is less than the lower limit threshold;

[0154] The keep-alive message sending module 510 is used to generate a second RTP keep-alive message according to the first response interval in response to satisfying the keep-alive message sending trigger rule, and send the second RTP keep-alive message to the second media device, so that the second media device sends the first RTP keep-alive message to the first media device regularly according to the first response interval.

[0155] In some embodiments, the receiving interval calculation module 504 of the present application includes:

[0156] An interval updating unit, configured to update an interval average value according to the message receiving interval and a preset smoothing factor;

[0157] An upper threshold value determination unit, configured to use the product of the interval average value and the network variation coefficient as the upper threshold value; wherein the network variation coefficient is a pre-set coefficient greater than 1;

[0158] The lower threshold determination unit is used to use the ratio between the interval average value and the network variation coefficient as the lower threshold.

[0159] In some embodiments, the media stream keep-alive device 500 of the present application further includes:

[0160] A loss of connection determination interval determination module, configured to determine a loss of connection determination interval according to the first response interval;

[0161] A disconnection determination module, configured to determine that the second media device is disconnected if the first RTP keep-alive message is not received within a disconnection determination interval;

[0162] The disconnection module is used to disconnect the first media device and the second media device and release resources when it is determined that the second media device is disconnected or fails the keep-alive check.

[0163] In some embodiments, the keep-alive check module 502 of the present application includes:

[0164] A message information extraction unit, used to extract a first device identifier and a first network connection information from the first RTP message, respectively; wherein the first device identifier is a device identifier of a video acquisition device involved in the current media stream transceiving interaction of the second media device, and the first network connection information is network connection information involved in the current media stream transceiving interaction of the second media device;

[0165] A first verification unit is configured to compare and verify the first device identifier with a pre-acquired target device identifier if the first RTP keep-alive message is the first keep-alive message received by the first media device in this media stream transceiver interaction, and save the first network connection information as the target network connection information if the comparison and verification pass;

[0166] The second verification unit is used to compare and verify the first device identifier and the target device identifier, and to compare and verify the first network connection information and the target network connection information if the first RTP keep-alive message is not the first keep-alive message received by the first media device in this media stream sending and receiving interaction.

[0167] In some embodiments, the keep-alive message sending module 510 of the present application includes:

[0168] An information acquisition unit, configured to acquire a second device identifier and second network connection information; wherein the second device identifier is a device identifier of a video acquisition device involved in the current media stream transceiving interaction of the first media device, and the second network connection information is network connection information involved in the current media stream transceiving interaction of the first media device;

[0169] A message generation unit is used to generate the second RTP keep-alive message according to the first response interval, the second device identifier and the second network connection information, so that the extended header information of the second RTP keep-alive message carries the first response interval, the second device identifier and the second network connection information.

[0170] In some embodiments, the first network connection information includes the network address of the second media device, the port information corresponding to the current media stream transceiver interaction of the second media device, and the SSRC corresponding to the second media device;

[0171] The second network connection information includes the network address of the first media device, the port information corresponding to the first media device in the current media stream sending and receiving interaction, and the SSRC corresponding to the first media device.

[0172] In some embodiments, the triggering rule for sending the keep-alive message is to determine whether a message sending period has arrived, and the message sending period is determined according to a second response interval carried by the first RTP keep-alive message.

[0173] In one embodiment, the present application further provides a storage medium storing computer-readable instructions. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the media stream keep-alive method in any embodiment.

[0174] In one embodiment, the present application further provides a media stream transceiver device, in which computer-readable instructions are stored. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the media stream keep-alive method in any embodiment.

[0175] Indicatively, Figure 6 This is a schematic diagram of the internal structure of a media stream transceiver device provided in an embodiment of the present application. In one example, the media stream transceiver device may be a video acquisition device, a streaming media server, or an electronic terminal. Figure 6 The media stream transceiver device 900 includes a processing component 902, which further includes one or more processors, and a memory resource represented by a memory 901, which is used to store instructions that can be executed by the processing component 902, such as an application. The application stored in the memory 901 may include one or more modules, each corresponding to a set of instructions. In addition, the processing component 902 is configured to execute instructions to perform the steps of the media stream keep-alive method described in any of the above embodiments.

[0176] The media stream transceiver device 900 may further include a power supply component 903 configured to perform power management of the media stream transceiver device 900 , a wired or wireless network interface 904 configured to connect the media stream transceiver device 900 to a network, and an input / output (I / O) interface 905 .

[0177] Those skilled in the art can understand that the internal structure of the media stream transceiver device shown in the present application is merely a block diagram of a partial structure related to the scheme of the present application, and does not constitute a limitation on the media stream transceiver device to which the scheme of the present application is applied. The specific media stream transceiver device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0178] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply that there is any such actual relationship or order between these entities or operations. Moreover, the term "include", "comprise" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, article or equipment including a series of elements not only includes those elements, but also includes other elements not clearly listed, or also includes elements inherent to such process, method, article or equipment. In the absence of more restrictions, the elements defined by the sentence "including one..." do not exclude the existence of other identical elements in the process, method, article or equipment including the elements. Herein, "one", "one", "said", "the" and "it" may also include plural forms, unless the context clearly indicates another way. A plurality refers to at least two cases, such as 2, 3, 5 or 8, etc. "And / or" includes any and all combinations of the relevant listed items.

[0179] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can refer to each other.

[0180] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A media stream keep-alive method, characterized in that: The method is applied to a first media device configured with a first response interval, wherein the first media device is any media stream transceiver device in a media stream transmission system; the method comprises: When receiving a first RTP keep-alive message sent by a second media device, performing a keep-alive check on the first RTP keep-alive message; wherein the second media device is a media stream transceiver device in the media stream transmission system that performs media stream transceiver interaction with the first media device; When the keep-alive check passes, the message receiving interval is calculated according to the latest receiving time and the previous receiving time of the first RTP keep-alive message, and the upper limit threshold and the lower limit threshold are determined respectively; If the message receiving interval is greater than the upper threshold, lowering the first response interval; If the message receiving interval is less than the lower limit threshold, increasing the first response interval; In response to satisfying the triggering rule for sending the keep-alive message, a second RTP keep-alive message is generated according to the first response interval, and the second RTP keep-alive message is sent to the second media device, so that the second media device sends the first RTP keep-alive message to the first media device periodically according to the first response interval.

2. The method according to claim 1, characterized in that The step of respectively determining the upper threshold and the lower threshold comprises: According to the message receiving interval and the preset smoothing factor, updating the interval average value; The product of the interval average value and the network variation coefficient is used as the upper limit threshold; wherein the network variation coefficient is a pre-set coefficient greater than 1; The ratio of the interval average value to the network variation coefficient is used as the lower limit threshold.

3. The method according to claim 1, characterized in that The method further comprises: Determine a connection loss determination interval according to the first response interval; If the first RTP keep-alive message is not received within the disconnection determination interval, it is determined that the second media device is disconnected; When it is determined that the second media device is disconnected or fails the keep-alive check, the connection between the first media device and the second media device is disconnected, and resources are released.

4. The method according to claim 1, characterized in that: The performing keep-alive verification on the first RTP keep-alive message includes: Extracting a first device identifier and a first network connection information from the first RTP message respectively; wherein the first device identifier is a device identifier of a video acquisition device involved in the current media stream transceiving interaction of the second media device, and the first network connection information is network connection information involved in the current media stream transceiving interaction of the second media device; If the first RTP keep-alive message is the first keep-alive message received by the first media device in this media stream transceiver interaction, the first device identifier is compared and verified with a pre-acquired target device identifier, and if the comparison and verification pass, the first network connection information is saved as the target network connection information; If the first RTP keep-alive message is not the first keep-alive message received by the first media device in this media stream transceiver interaction, the first device identifier and the target device identifier are compared and verified, and the first network connection information and the target network connection information are compared and verified.

5. The method according to claim 4, characterized in that The generating a second RTP keep-alive message according to the first response interval includes: Obtain a second device identifier and a second network connection information; wherein the second device identifier is a device identifier of a video acquisition device involved in the current media stream transceiving interaction of the first media device, and the second network connection information is network connection information involved in the current media stream transceiving interaction of the first media device; The second RTP keep-alive message is generated according to the first response interval, the second device identifier and the second network connection information, so that the extended header information of the second RTP keep-alive message carries the first response interval, the second device identifier and the second network connection information.

6. The method according to claim 4 or 5, characterized in that: The first network connection information includes the network address of the second media device, the port information corresponding to the second media device in the current media stream transceiver interaction, and the SSRC corresponding to the second media device; The second network connection information includes the network address of the first media device, the port information corresponding to the first media device in the current media stream sending and receiving interaction, and the SSRC corresponding to the first media device.

7. The method according to any one of claims 1 to 5, characterized in that: The sending trigger rule of the keep-alive message is to determine whether the message sending period has arrived, and the message sending period is determined according to the second response interval carried by the first RTP keep-alive message.

8. A media stream keep-alive device, characterized in that: The device is applied to a first media device configured with a first response interval, wherein the first media device is any media stream transceiver device in a media stream transmission system; the device comprises: A keep-alive verification module, configured to perform a keep-alive verification on a first RTP keep-alive message sent by a second media device when the first RTP keep-alive message is received; wherein the second media device is a media stream transceiver device in the media stream transmission system that performs media stream transceiver interaction with the first media device; A receiving interval calculation module, used to calculate the message receiving interval according to the latest receiving time and the previous receiving time of the first RTP keep-alive message when the keep-alive check passes, and determine the upper limit threshold and the lower limit threshold respectively; A first adjustment module, configured to lower the first response interval if the message receiving interval is greater than the upper threshold; A second adjustment module, configured to increase the first response interval if the message receiving interval is less than the lower limit threshold; A keep-alive message sending module is used to generate a second RTP keep-alive message according to the first response interval in response to meeting the keep-alive message sending trigger rule, and send the second RTP keep-alive message to the second media device, so that the second media device sends the first RTP keep-alive message to the first media device regularly according to the first response interval.

9. A storage medium, characterized in that: The storage medium stores computer-readable instructions, and when the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the media stream keep-alive method according to any one of claims 1 to 7.

10. A media stream transceiver device, characterized in that: include: one or more processors, and memory; The memory stores computer-readable instructions, and when the computer-readable instructions are executed by the one or more processors, the steps of the media stream keep-alive method according to any one of claims 1 to 7 are performed.

Images