A security video session synchronization source conflict exception suppression system and method

Abstract

The application provides a security video session synchronization source conflict exception suppression system and method, which comprises the following steps: establishing a media buffer between a media sender and a media receiver, combining a synchronization source SSRC enable / disable list, protecting a back-end media receiver, and suppressing synchronization source conflict exceptions. Through technical means, the SSRC is weakened, the three main SSRC conflicts of the public cloud can be effectively avoided to cause faults, and the SSRC conflicts can be conditionally allowed without causing faults, so that the SSRC conflict exception suppression is achieved. For the conflict exceptions that cannot be suppressed, timely identification, timely self-repair and recovery of availability can be achieved.

Description

Technical Field

[0001] The present invention relates to the audio and video field of cloud-native security video surveillance, and more specifically to a system and method for suppressing conflict anomalies in synchronization signal sources of security video sessions. Background Art

[0002] GB28181, short for "Technical Requirements for Information Transmission, Exchange, and Control of Networked Security Video Surveillance Systems," is a security surveillance technical specification proposed by the Science and Technology Information Bureau of the Ministry of Public Security (hereinafter referred to as the national standard). It is a control protocol based on SIP (Session Initialization Protocol) and is widely used in national safe city, transportation, and road surveillance systems. Traditional video surveillance services are typically deployed within an intranet environment, connecting to managed front-end cameras through the national standard protocol to implement a complete security system. Nowadays, with the iteration of technology and the growing demand for video surveillance in the cloud, in order to provide customers with PaaS cloud video surveillance services, many manufacturers have migrated national standard services to the cloud, thereby providing a unified standard of surveillance video access and management services to the majority of public cloud customers. However, as the service form has changed from private deployment to public cloud and opened to public network customers, a series of technical difficulties have emerged that need to be overcome, such as how to adapt to the complexity and diversity of public cloud customers' front-end devices, how to adapt to multiple firewalls and address mappings, etc., and most importantly, how to meet the requirements of modern cloud services for security, elasticity and high availability. All of these require the optimization and transformation of existing national standard services.

[0003] Generally speaking, to complete the national standard service for front-end devices (network IP camera IPC, network video recorder NVR, security monitoring platform Platform, etc.) video management, it is necessary to configure the national standard signaling service (hereinafter referred to as SIP service) IP address and SIP port on the front-end device. Then the front-end device will complete the registration with the SIP service through the Register request specified in RFC3261 according to the national standard requirements, and use the Invite request to carry SDP (Session Description Protocol) for media information exchange, and finally complete the audio and video on demand of the front-end device. The complete interaction process is as follows: Figure 1 shown.

[0004] SDP is mainly used to describe the initialization of multimedia sessions. In the complete national standard real-time audio and video on-demand process, both the Invite request and the 200 OK response carry an SDP message body. The SDP message body of the Invite describes the IP address (DST-IP), port (DST-PORT), media format, and SSRC (DST-SSRC) (Synchronization Source) of the media server receiving the streaming media. The SDP message body of the 200 OK response describes the IP address (SRC-IP), port (SRC-PORT), media format, and SSRC (SRC-SSRC) of the media sender.

[0005] Typically, in a privately deployed intranet environment, the media receiver can verify the received media stream by combining the DST-PORT, SRC-IP, SRC-PORT, and SRC-SSRC in the SDP of the front-end device's 200 OK response into a four-tuple, thereby binding the stream to a specific front-end device. However, in a public cloud environment, front-end devices are often behind NAT (Network Address Translation) and are unable to perceive their true egress IP and port. This means that the SRC-IP and SRC-PORT lose credibility. Furthermore, public cloud services often use a single-port service model for security and management reasons, making the DST-PORT meaningless. Therefore, the media receiver can no longer use the original four-tuple verification method and is forced to use a single SRC-SSRC for binding, which carries a significant risk of conflict.

[0006] The SSRC format specified by the national standard is as follows: dddddddddd. The first digit is the identification digit of the historical or real-time media stream, the second to sixth digits are the 4th to 8th digits of the SIP monitoring domain ID as the domain identifier, and the seventh to tenth digits are the domain media stream identifier, which is a four-digit decimal integer that does not repeat the last four digits of the SSRC value of the media stream generated in the current domain. This also means that the number of SSRCs available in the same domain is only 10,000, that is, 0000 to 9999. Secondly, the national standard front-end equipment is diverse, and there are often abnormal situations where it is impossible to request streaming. After the public cloud is connected to a large number of devices, it is found that the abnormalities mainly have the following characteristics:

[0007] 1. The SSRC assigned by the media receiver cannot be used for streaming, and 0 or a random SSRC generated by itself is used instead.

[0008] 2. Unable to stop streaming normally. Some devices will continue to use the SSRC marked as expired by the media receiver to push the stream after deregistration.

[0009] 3. Send multiple streams. Some devices send multiple streams to the same platform at the same time, that is, they occupy multiple SSRCs at the same time, push streams repeatedly and cannot be stopped.

[0010] Therefore, in addition to handling normally assigned SSRCs, media receivers must also be vigilant against unusual streams with random SSRCs to avoid conflicts. Once an SSRC conflict occurs at the media receiver, it can disrupt the correspondence between the device and the monitoring screen, commonly known as "surveillance screen distortion." This failure is extremely serious and should be avoided as much as possible. This is a new problem that arises after traditional national standard services become cloud-native.

[0011] To address these issues, the present invention provides a GB / T28181 security video session synchronization source conflict anomaly suppression method. This method, applicable to cloud-native national standard monitoring services, suppresses image errors caused by synchronization source conflicts due to abnormal devices accessing public cloud environments or network attacks, which can lead to unavailability of audio and video access services. This method is part of the high availability capabilities of cloud-native video monitoring services. This method can also increase the theoretical access capacity limit of a single media receiver, thereby reducing costs and increasing efficiency. Summary of the Invention

[0012] The present invention has been made in view of the above-mentioned problems.

[0013] According to one aspect of the present invention, a security video session synchronization source conflict anomaly suppression system is proposed, which includes four modules: an SSRC management module, a source detection module, a media stream buffer module, and a media receiver module;

[0014] The SSRC management module: performs unified management of SSRC, performs time management of SSRC, maintains SSRC revocation / validation lists based on cache middleware such as Redis, and records the SSRC's effective time and revocation time, the SSRC's currently bound IP address, and the front-end device ID; sets validity periods for all entries in the revocation list to prevent unlimited expansion of the list space; provides SSRC generation and revocation interfaces, and provides SSRC validity and revocation status queries;

[0015] The source detection module: When the push source address of the same SSRC suddenly changes to two, it analyzes the source address type, distinguishes between 4G / 5G networks and fixed broadband, and provides an interface to determine the correlation between two different IP port addresses. The comprehensive network type and IP address analysis gives the following results: 1) consistent network type; 2) consistent location; 3) consistent operator; 4) consistent geographical location; 5) consistent IP; The higher the grade number, the more likely this IP is the source IP of the original device's push stream. If the scores of the two newly added IPs are consistent, the module attempts to parse the RTP stream to obtain media stream attribute information and compare it with the original stream attributes. If the attributes are inconsistent or consistent, the original device is re-pulled to resolve the conflict.

[0016] The media stream buffer module supports horizontal expansion and load balancing, pre-checks and caches media streams, compares media stream SSRC and media stream export information with records in the SSRC validation table and revocation table, collaborates with the source detection module, identifies illegal streams and discards them along with the cache, and merges the legitimate streams into the cache and passes them to the media receiver module for processing;

[0017] The media receiver module acts as a streaming media processor to perform AI analysis, media storage, and media distribution services, and updates the actual processed media attributes (resolution, encoding type, frame rate, and key frame frequency) into the SSRC validation table.

[0018] The present invention also proposes a method for suppressing conflict anomalies of synchronization signal sources in security video sessions. The method is applied to the above-mentioned system and includes a media buffer analysis process:

[0019] When the media buffer receives a media stream from invited sender A, it caches the media stream and checks the synchronization source SSRC validation table to see if SSRC = X is valid and the address information is consistent. The buffer then passes the cached content along with the real-time stream to the actual media stream receiver for further processing.

[0020] When the media buffer receives a non-invited media stream from abnormal device 01, it queries the synchronization source SSRC validity table and finds that SSRC = Y is not valid. It directly writes abnormal device 01 and its address information and SSRC into the SSRC revocation table for blocking, and discards all cached media stream content and real-time media streams.

[0021] When the media buffer receives a media stream from invited sender B, it caches the media stream and checks the synchronization source SSRC validation table to see that SSRC = Y is valid and the address information is consistent. The buffer then passes the cached content along with the real-time stream (excluding the stream recorded in the SSRC revocation table in step 2) to the actual media stream receiver for further processing.

[0022] When the media buffer receives a non-active invitation media stream from abnormal device 02, it queries the synchronization source SSRC validity table and finds that SSRC = Y is valid and there is an accepted media stream. It then compares the address information and media fingerprint in the validity table level by level and finds that the trust level of media stream sender B is higher than that of abnormal device 02. The abnormal device 02 and its address information and SSRC are written into the SSRC revocation table for blocking, and the cached media stream content and real-time media stream are all discarded.

[0023] Compared with the prior art, this application has the following beneficial effects:

[0024] Existing national standard video surveillance services often use a multi-port model, whereby the destination port, SSRC, source IP, and source port are combined into a four-tuple determination to ensure the correct binding relationship. However, this approach is not suitable for public cloud services open to the internet. Firstly, the source IP and port lose accuracy, and secondly, the multi-port model is not convenient for security supervision. Therefore, the original four-tuple determination has to be degraded to a single-tuple determination. This cannot avoid serious service failures caused by synchronization source SSRC conflicts in special circumstances. The synchronization source SSRC conflict suppression method described in this invention weakens SSRC through technical means, effectively avoiding failures caused by the three major SSRC conflicts mentioned above in public clouds. SSRC conflicts can also be conditionally allowed without causing failures, thereby effectively suppressing SSRC conflict anomalies. Even for conflict anomalies that cannot be suppressed, timely identification and self-repair can be achieved to restore availability. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The above and other objects, features, and advantages of the present invention will become more apparent through a more detailed description of the embodiments of the present invention with reference to the accompanying drawings. The accompanying drawings are provided to provide a further understanding of the embodiments of the present invention and constitute a part of the specification. Together with the embodiments of the present invention, they are used to explain the present invention and are not intended to limit the present invention. In the drawings, the same reference numerals generally represent the same components or steps.

[0026] Figure 1 A schematic diagram of a real-time streaming on-demand interaction process according to an embodiment of the present invention is shown;

[0027] Figure 2 A schematic diagram of a media buffer analysis process according to an embodiment of the present invention is shown;

[0028] Figure 3 A schematic diagram of RTP fixed message fields according to an embodiment of the present invention is shown;

[0029] Figure 4 A schematic diagram of media buffer operation according to an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0030] In order to make the purpose, technical solutions and advantages of the present invention more apparent, exemplary embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments of the present invention, and it should be understood that the present invention is not limited to the exemplary embodiments described herein. Based on the embodiments of the present invention described in the present invention, all other embodiments obtained by those skilled in the art without creative work should fall within the scope of protection of the present invention.

[0031] Example 1:

[0032] To address the aforementioned issues, we propose a method and system for suppressing synchronization source conflicts in security video sessions. Applicable to cloud-native national standard surveillance services, this method mitigates image errors caused by synchronization source conflicts due to abnormal devices connected to public cloud environments or network attacks, which can lead to unavailability of audio and video access services. This method is part of the high availability capabilities of cloud-native video surveillance services. This method can also increase the theoretical access capacity of individual media receivers, thereby reducing costs and increasing efficiency.

[0033] Specifically, a security video session synchronization source conflict anomaly suppression system according to an embodiment of the present invention includes: four modules: an SSRC management module, a source detection module, a media stream buffer module, and a media receiver module;

[0034] The SSRC management module: performs unified management of SSRC, performs time management of SSRC, maintains SSRC revocation / validation lists based on cache middleware such as Redis, and records the SSRC's effective time and revocation time, the SSRC's currently bound IP address, and the front-end device ID; sets validity periods for all entries in the revocation list to prevent unlimited expansion of the list space; provides SSRC generation and revocation interfaces, and provides SSRC validity and revocation status queries;

[0035] The source detection module: When the push source address of the same SSRC suddenly changes to two, it analyzes the source address type, distinguishes between 4G / 5G networks and fixed broadband, and provides an interface to determine the correlation between two different IP port addresses. The comprehensive network type and IP address analysis gives the following results: 1) consistent network type; 2) consistent location; 3) consistent operator; 4) consistent geographical location; 5) consistent IP; The higher the grade number, the more likely this IP is the source IP of the original device's push stream. If the scores of the two newly added IPs are consistent, the module attempts to parse the RTP stream to obtain media stream attribute information and compare it with the original stream attributes. If the attributes are inconsistent or consistent, the original device is re-pulled to resolve the conflict.

[0036] The media stream buffer module supports horizontal expansion and load balancing, pre-checks and caches media streams, compares media stream SSRC and media stream export information with records in the SSRC validation table and revocation table, collaborates with the source detection module, identifies illegal streams and discards them along with the cache, and merges the legitimate streams into the cache and passes them to the media receiver module for processing;

[0037] The media receiver module acts as a streaming media processor to perform AI analysis, media storage, and media distribution services, and updates the actual processed media attributes (resolution, encoding type, frame rate, and key frame frequency) into the SSRC validation table.

[0038] Example 2:

[0039] The present invention also proposes a method for suppressing abnormal conflicts of synchronization signal sources of security video conversations, which is applied to the above system, such as Figure 2 As shown, the media buffer analysis process is as follows:

[0040] 1. When the media buffer receives a media stream from invited sender A, it caches the media stream and checks the synchronization source SSRC validation table to see if SSRC = X is valid and the address information is consistent. The buffer then passes the cached content along with the real-time stream to the actual media stream receiver for further processing.

[0041] 2. When the media buffer receives a non-invited media stream from the abnormal device 01, it queries the synchronization source SSRC validity table and finds that SSRC = Y is not valid. The abnormal device 01 and its address information and SSRC are directly written into the SSRC revocation table for blocking, and the cached media stream content and real-time media stream are all discarded;

[0042] 3. When the media buffer receives the media stream from the invited sender B, it will cache the media stream and find that SSRC = Y is valid according to the synchronization source SSRC validation table. The address information is verified to be consistent. The buffered content is then passed along with the real-time stream (excluding the stream recorded in the SSRC revocation table in step 2) to the actual media stream receiver for further processing.

[0043] 4. When the media buffer receives a non-invited media stream from abnormal device 02, it queries the synchronization source SSRC validation table and finds that SSRC = Y is valid and there is an accepted media stream. It then compares the address information and media fingerprint in the validation table level by level and finds that the trust level of media stream sender B is higher than that of abnormal device 02. The abnormal device 02 and its address information and SSRC are written into the SSRC revocation table for blocking, and the cached media stream content and real-time media stream are all discarded.

[0044] Specifically, the present invention uses a synchronization source SSRC validation table to record the binding status of the effective SSRC, the actual source IP of the front-end device signaling, and the fingerprint information consisting of media stream attributes (resolution, encoding type, frame rate, key frame frequency), and uses a synchronization source SSRC revocation table to record the network IP port of expired SSRC and illegal media stream SSRC.

[0045] The present invention adds a media stream buffer between the actual media receiver and the media sender to monitor the real-time media stream. In combination with the synchronization source SSRC validation table, the present invention screens out illegal media streams (i.e., unaccepted or expired media streams) based on the source IP address, marks them, and records them in the synchronization source SSRC revocation table. The buffer only allows legal RTP streams recorded in the SSRC validation table. When the revoked SSRC is reactivated, the illegal media streams recorded in the SSRC revocation table need to be blocked to prevent incorrect binding.

[0046] The present invention uses the signaling module to obtain the real-time IP address of the front-end device's signaling interaction outlet (ignoring the SRC-IP provided in the SDP) and combines it with the SSRC to form a new binary for media stream binding. The source IP address of the front-end device's signaling heartbeat period is recorded and compared with the source IP address of the media stream in real time. If there is a long-term IP inconsistency, it is determined to be an SSRC conflict, posing a risk of abnormal monitoring images. The service should immediately restart the current session to correct the anomaly.

[0047] The application of the present invention can be before the media stream reaches the actual media stream receiver, such as Figure 3 As shown in the figure, by reading the SSRC and source IP port of the RTP message header, and combining the fingerprint information composed of media attributes when necessary, the legitimacy of the stream is judged and filtered, reducing the load of computationally intensive services such as back-end streaming media. During the judgment process, data will be cached to prevent data loss. After the legitimacy check is passed, the cached data will be passed to the actual media stream receiver to prevent data loss. On the contrary, if the legitimacy check fails, the cached data will be cleared and the data packet will be permanently dropped, as shown in the figure. Figure 4 shown.

[0048] The key technical point of the present invention is a method and system for suppressing synchronization source conflict anomalies based on security video session, which establishes a media buffer between the media sender and the media receiver and combines the synchronization source SSRC validation / revocation list to protect the back-end media receiver and suppress synchronization source conflict anomalies.

[0049] Although example embodiments have been described herein with reference to the accompanying drawings, it should be understood that the above example embodiments are merely illustrative and are not intended to limit the scope of the present invention. Various changes and modifications may be made therein by those skilled in the art without departing from the scope and spirit of the present invention. All such changes and modifications are intended to be included within the scope of the present invention as claimed in the appended claims.

[0050] In the description provided herein, numerous specific details are described. However, it is understood that embodiments of the present invention may be practiced without these specific details. In some instances, well-known methods, structures, and techniques are not shown in detail so as not to obscure the understanding of this description.

[0051] Similarly, it should be understood that, in order to streamline the present invention and aid understanding of one or more of the various inventive aspects, in the description of exemplary embodiments of the present invention, various features of the present invention are sometimes grouped together into a single embodiment, figure, or description thereof. However, this approach to the present invention should not be interpreted as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as reflected in the corresponding claims, the inventive concept is that the corresponding technical problem can be solved with fewer than all the features of a single disclosed embodiment. Accordingly, the claims following the detailed description are hereby expressly incorporated into this detailed description, with each claim standing on its own as a separate embodiment of the present invention. Those skilled in the art will understand that, except where mutually exclusive, all features disclosed in this specification (including the accompanying claims, abstract, and drawings), as well as all processes or elements of any method or apparatus disclosed therein, may be combined in any combination. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature serving the same, equivalent, or similar purpose.

[0052] Furthermore, those skilled in the art will appreciate that although some embodiments described herein include certain features included in other embodiments but not other features, combinations of features from different embodiments are intended to be within the scope of the present invention and to form different embodiments. For example, in the claims, any of the claimed embodiments may be used in any combination.

[0053] It should be noted that the above embodiments illustrate rather than limit the invention, and that a person skilled in the art may devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between brackets should not be construed as limiting the claims. The word "comprising" does not exclude the presence of components or steps not listed in the claims. The word "a" or "an" preceding a component does not exclude the presence of a plurality of such components. The present invention may be implemented by means of hardware comprising several different components and by means of suitably programmed computers. In a unit claim enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third etc. does not indicate any order. These words may be interpreted as names.

[0054] The foregoing description is merely a specific embodiment of the present invention or an illustration of a specific embodiment. The scope of protection of the present invention is not limited thereto. Any modifications or substitutions that can be readily conceived by a person skilled in the art within the technical scope disclosed in the present invention are intended to be encompassed by the scope of protection of the present invention. The scope of protection of the present invention shall be subject to the scope of protection of the claims.

Claims

1. A security video session synchronization signal source conflict anomaly suppression system, characterized in that: include: SSRC Management Module: Provides unified management of SSRC, performs time management on SSRC, maintains SSRC revocation / validation lists based on Redis cache middleware, records the SSRC's effective time and revocation time, the SSRC's currently bound IP address and front-end device ID; sets validity periods for all entries in the revocation list to prevent unlimited expansion of the list space; provides SSRC generation and revocation interfaces, and provides SSRC validity and revocation status queries; Source detection module: When the same SSRC source address for streaming suddenly changes to two, the module analyzes the source address type, distinguishes between 4G / 5G networks and fixed broadband, and provides an interface to determine the correlation between two different IP port addresses. The module analyzes the network type and IP address based on the following results: 1) consistent network type; 2) consistent location; 3) consistent operator; 4) consistent geographic location; 5) consistent IP address. The higher the grade number, the more likely the IP address is the source IP address for streaming from the original device. If the scores of the two newly added IP addresses are consistent, the module attempts to parse the RTP stream to obtain media stream attribute information and compare it with the original stream attributes. If the attributes are inconsistent or consistent, the original device is re-pulled to resolve the conflict. Media stream buffering module: supports horizontal expansion, load balancing, pre-checks and caches media streams, compares media stream SSRC and media stream export information with records in the SSRC validation table and revocation table, collaborates with the source detection module to identify illegal streams and discard them along with the cache, and merges the legitimate streams into the cache and passes them to the media receiver module for processing; Media Receiver Module: As a streaming media processor, it performs AI analysis, media storage, and media distribution services, and updates the actual processed media attributes (resolution, encoding type, frame rate, and key frame frequency) to the SSRC effective table.

2. The system according to claim 1, wherein: The synchronization source SSRC validity table is used to record the binding status of the effective SSRC, the actual source IP of the front-end device signaling, and the fingerprint information composed of resolution, encoding type, frame rate, key frame frequency, etc. The synchronization source SSRC revocation table is used to record the network IP port of expired SSRC and illegal media stream SSRC.

3. The system according to claim 1, wherein: A media stream buffer is added between the actual media receiver and the media sender to monitor the real-time media stream. In combination with the synchronization source SSRC validity table, the source IP address is used to filter out illegal media streams, that is, media streams that have not been accepted or expired, and mark them and record them in the synchronization source SSRC revocation table. The buffer only allows legal RTP streams recorded in the SSRC validity table. When the revoked SSRC is reactivated, the illegal media streams recorded in the SSRC revocation table need to be blocked to prevent incorrect binding.

4. The system according to claim 1, wherein: The real-time IP address of the front-end device's signaling interaction outlet is obtained through the signaling module and combined with the SSRC to form a new binary group to participate in the media stream relationship binding; the source IP address of the front-end device's signaling periodic heartbeat is recorded and compared with the media stream source IP address in real time. Once a long period of IP inconsistency occurs, it is judged as an SSRC conflict and there is a risk of abnormal monitoring screen. The service should immediately restart the current session and correct the abnormality.

5. The system according to claim 1, wherein: Before the media stream reaches the actual media stream receiver, the SSRC and source IP port in the RTP message header are read and combined with the fingerprint information composed of media attributes to analyze and filter the legitimacy of the stream, reducing the load of the back-end streaming media computing-intensive service. During the analysis process, data will be cached to prevent data loss. After the legitimacy check passes, the cached data will be passed to the actual media stream receiver to prevent data loss. On the contrary, if the validity check fails, the cache data will be cleared and the data packet will be permanently dropped.

6. A method for suppressing abnormal conflicts in synchronization sources of security video conversations, characterized by: The method is applied to the system according to claim 1, including a media buffer analysis process: When the media buffer receives a media stream from invited sender A, it caches the media stream and checks the synchronization source SSRC validation table to see if SSRC = X is valid and the address information is consistent. The buffer then passes the cached content along with the real-time stream to the actual media stream receiver for further processing. When the media buffer receives a non-invited media stream from abnormal device 01, it queries the synchronization source SSRC validity table and finds that SSRC = Y is not valid. It directly writes abnormal device 01 and its address information and SSRC into the SSRC revocation table for blocking, and discards all cached media stream content and real-time media streams. When the media buffer receives the media stream from invited sender B, it caches the media stream and checks the synchronization source SSRC validation table to see that SSRC = Y is valid and the address information is consistent. It then passes the cached content along with the real-time stream to the actual media stream receiver for further processing. When the media buffer receives a non-active invitation media stream from abnormal device 02, it queries the synchronization source SSRC validity table and finds that SSRC = Y is valid and there is an accepted media stream. It then compares the address information and media fingerprint in the validity table level by level and finds that the trust level of media stream sender B is higher than that of abnormal device 02. The abnormal device 02 and its address information and SSRC are written into the SSRC revocation table for blocking, and the cached media stream content and real-time media stream are all discarded.

7. The method according to claim 6, characterized in that Also includes: The synchronization source SSRC validity table is used to record the binding status of the effective SSRC, the actual source IP of the front-end device signaling, and the fingerprint information composed of resolution, encoding type, frame rate, key frame frequency, etc. The synchronization source SSRC revocation table is used to record the network IP port of expired SSRC and illegal media stream SSRC.

8. The method according to claim 6, characterized in that Also includes: A media stream buffer is added between the actual media receiver and the media sender to monitor the real-time media stream. In combination with the synchronization source SSRC validity table, the source IP address is used to filter out illegal media streams, that is, media streams that have not been accepted or expired, and mark them and record them in the synchronization source SSRC revocation table. The buffer only allows legal RTP streams recorded in the SSRC validity table. When the revoked SSRC is reactivated, the illegal media streams recorded in the SSRC revocation table need to be blocked to prevent incorrect binding.

9. The method according to claim 6, characterized in that Also includes: Obtain the real-time IP address of the front-end device's signaling interaction outlet through the signaling module and combine it with the SSRC to form a new binary to participate in media stream relationship binding; Record the source IP of the signaling periodic heartbeat of the front-end device and compare it with the source IP of the media stream in real time. Once there is a long period of IP inconsistency, it is judged as an SSRC conflict and there is a risk of abnormal monitoring screen. The service should immediately restart the current session and correct the abnormality.

10. The method according to claim 6, characterized in that Also includes: Before the media stream reaches the actual media stream receiver, the SSRC and source IP port in the RTP message header are read and combined with the fingerprint information composed of media attributes to analyze and filter the legitimacy of the stream, reducing the load of the back-end streaming media computing-intensive service. During the analysis process, data will be cached to prevent data loss. After the legitimacy check passes, the cached data will be passed to the actual media stream receiver to prevent data loss. On the contrary, if the validity check fails, the cache data will be cleared and the data packet will be permanently dropped.

Images