Encrypted video and video key encryption key synchronous transmission method and related device

Abstract

The invention discloses an encrypted video and video key encryption key synchronous transmission method and a related device thereof, and the method comprises the steps: after an SIP server receives an Invite request which is sent by a media stream receiver and carries an SDP message, the connection between a media server and a media stream sender is established through three-party call control; establishing a connection between a media stream receiver and a media server through a B2BUA proxy mode; and when the VKEK is changed, the SIP server sends a message to notify the media server, the changed VKEK is issued to each path of encrypted video distribution link by the media server, then the changed VKEK is packaged into an RTP data packet by each link, and the RTP data packet is sent to a media stream receiver before the next key frame is sent to decrypt the video. The problem that the streaming media VKEK and the encrypted video stream are not synchronous is solved, meanwhile, the development difficulty of media management and the client side is reduced, and popularization is facilitated.

Description

Technical Field

[0001] This application relates to the field of information security technology, and in particular to a method and related apparatus for synchronous transmission of encrypted video and video key encryption key. Background Technology

[0002] Existing solutions suffer from a disconnect between the Video Key Encryption Key (VKEK) update and the video stream when transmitting encrypted video. This often results in screen flickering on clients during live streaming or playback because they fail to receive the new key in a timely manner. Furthermore, existing mechanisms suffer from development complexity, high network dependency, and resource waste. Summary of the Invention

[0003] This application provides a method and related apparatus for synchronous transmission of encrypted video and video key encryption key, which improves the problem of asynchronous transmission between streaming media VKEK and encrypted video stream, while reducing the difficulty of media management and client development, and facilitating promotion.

[0004] In view of this, the first aspect of this application provides a method for synchronously transmitting encrypted video and video key encryption key, comprising:

[0005] After receiving an Invite request carrying a first SDP message from the media stream receiver, the SIP server establishes a media connection between the media server and the media stream sender through a three-way call control; the first SDP message includes the video source ID for the video on demand, the sender's media stream sequence number, the media stream receiver ID, and the receiver's media stream sequence number;

[0006] After completing the three-way call control, the SIP server adds an SSRC value to the Invite request carrying the first SDP message and forwards it to the media server, which then returns a successful response carrying the second SDP message. The second SDP message includes the IP address, port, media format, and SSRC value of the media stream sent by the media server.

[0007] The SIP server forwards the successful response of the request carrying the second SDP message to the media stream receiver, and forwards the ACK request returned by the media stream receiver to the media server;

[0008] When the video key encryption key changes, the SIP server sends a message carrying the changed video key encryption key to the media server. The media server then distributes the changed video key encryption key to all distribution encrypted video links of the media stream sender. Each distribution encrypted video link encapsulates the changed video key encryption key into an RTP data packet and sends the RTP data packet to the media stream receiver before the next video keyframe is sent. This allows the media stream receiver to decrypt the video keyframe based on the video key encryption key in the RTP data packet.

[0009] Optionally, the SIP server establishes a media connection between the media server and the media streamer via a three-way call control, including:

[0010] The SIP server sends an Invite request to the media server, and the media server returns a successful request response carrying a third SDP message to the SIP server; the third SDP message includes the IP address, port, and media format of the media stream received by the media server;

[0011] The SIP server sends an Invite request carrying a fourth SDP message to the media stream sender, and the media stream sender returns a successful request response carrying a fifth SDP message to the SIP server; the fourth SDP message is generated based on the third SDP message, and the fifth SDP message includes the IP address, port, media format, and SSRC field of the media stream sent by the media stream sender;

[0012] The SIP server sends an ACK request carrying the fifth SDP message to the media server and an ACK request without an SDP message to the media stream sender to establish Invite sessions with the media server and the media stream sender, respectively.

[0013] Optionally, the generation process of the fourth SDP message includes:

[0014] Modify the 's' field in the third SDP message to 'Play', add a 'y' field to describe the SSRC value, and add an 'f' field to describe the media parameters. 'Play' indicates real-time on-demand playback.

[0015] Optionally, the process by which each distributed encrypted video link encapsulates the modified video key encryption key into an RTP data packet includes:

[0016] Each encrypted video distribution link generates an RTP header based on its distribution index and system timestamp, and then appends a custom-defined packet header to the RTP header.

[0017] A 4-byte length reserve is encapsulated after the RTP header, and the 4-byte length reserve is assigned a value according to the length of the modified video key encryption key. Then, the modified video key encryption key is concatenated to obtain the encapsulated RTP data packet.

[0018] Optionally, the distribution encrypted video link sends the RTP data packet to the media stream receiver before the next video keyframe is sent, and then further includes:

[0019] Distribute encrypted video links and clear the video key encryption key information of the current path.

[0020] A second aspect of this application provides a system for synchronously transmitting encrypted video and video key encryption keys, comprising:

[0021] The media stream receiver is used to send an Invite request carrying a first SDP message to the SIP server. The first SDP message includes the video source ID for the video being played, the sender's media stream sequence number, the media stream receiver ID, and the receiver's media stream sequence number.

[0022] The SIP server is used to establish a media connection between the media server and the media stream sender through a three-way call control; after the three-way call control is completed, the SSRC value is added to the Invite request carrying the first SDP message and forwarded to the media server.

[0023] The media server is configured to return a successful response carrying a second SDP message after receiving an Invite request; the second SDP message includes the IP address, port, media format, and SSRC value of the media server sending the media stream.

[0024] The SIP server is also configured to forward a successful request response carrying the second SDP message to the media stream receiver;

[0025] The media stream receiver is also configured to return an ACK request to the SIP server after receiving a successful response to the request, and the SIP server will forward the ACK request to the media server.

[0026] The SIP server is also configured to send a message carrying the changed video key encryption key to the media server when the video key encryption key changes.

[0027] The media server is also used to distribute the modified video key encryption key to all distribution encrypted video links of the media stream sender, and each distribution encrypted video link encapsulates the modified video key encryption key into an RTP data packet, and sends the RTP data packet to the media stream receiver before the next video key frame is sent, so that the media stream receiver decrypts the video key frame according to the video key encryption key in the RTP data packet.

[0028] Optionally, the SIP server is specifically used for: establishing a media connection between the media server and the media streamer via three-way call control.

[0029] The SIP server sends an Invite request to the media server, and the media server returns a successful request response carrying a third SDP message to the SIP server; the third SDP message includes the IP address, port, and media format of the media stream received by the media server;

[0030] The SIP server sends an Invite request carrying a fourth SDP message to the media stream sender, and the media stream sender returns a successful request response carrying a fifth SDP message to the SIP server; the fourth SDP message is generated based on the third SDP message, and the fifth SDP message includes the IP address, port, media format, and SSRC field of the media stream sent by the media stream sender;

[0031] The SIP server sends an ACK request carrying the fifth SDP message to the media server and an ACK request without an SDP message to the media stream sender to establish Invite sessions with the media server and the media stream sender, respectively.

[0032] Optionally, the process by which each distributed encrypted video link encapsulates the modified video key encryption key into an RTP data packet includes:

[0033] Each encrypted video distribution link generates an RTP header based on its distribution index and system timestamp, and then appends a custom-defined packet header to the RTP header.

[0034] A 4-byte length reserve is encapsulated after the RTP header, and the 4-byte length reserve is assigned a value according to the length of the modified video key encryption key. Then, the modified video key encryption key is concatenated to obtain the encapsulated RTP data packet.

[0035] A third aspect of this application provides an electronic device, the device including a processor and a memory;

[0036] The memory is used to store program code and transmit the program code to the processor;

[0037] The processor is configured to execute, according to the instructions in the program code, any one of the methods for synchronous transmission of encrypted video and video key encryption key as described in the first aspect.

[0038] A fourth aspect of this application provides a computer-readable storage medium for storing program code, which, when executed by a processor, implements the method for synchronous transmission of encrypted video and video key encryption key as described in any of the first aspects.

[0039] As can be seen from the above technical solutions, this application has the following advantages:

[0040] The method for synchronous transmission of encrypted video and video key encryption key provided in this application directly informs the streaming media of the VKEK information received by the SIP server through the same streaming media server. When the streaming media is distributing, it encapsulates the VKEK into an RTP data packet and distributes it to all clients watching this camera before the next keyframe. This solves the problem of the streaming media VKEK being out of sync with the encrypted video stream, while reducing the difficulty of media management and client development, and making it easier to promote. Attached Figure Description

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

[0042] Figure 1 This application provides a schematic diagram of a live encrypted video process.

[0043] Figure 2 This application provides a schematic diagram of an encrypted video playback process for an embodiment of the present application.

[0044] Figure 3 A flowchart illustrating a method for synchronously transmitting encrypted video and video key encryption key according to an embodiment of this application;

[0045] Figure 4 This is another flowchart illustrating a method for synchronously transmitting encrypted video and video key encryption keys, provided in an embodiment of this application. Detailed Implementation

[0046] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0047] Please refer to Figure 1 In live encrypted video streaming, one approach involves the client playing RTSP (Real-Time Streaming Protocol) video. The standard design logic places the VKEK (Video Keying) in the SDP message (step 9) during the handshake process. However, live VKEKs have an expiration date. When the camera's encryption level is changed on the backend or the expiration time expires, a new VKEK is automatically generated for playback. In this case, the new VKEK needs to be sent to the designated client to replace it. Normally, this is done by disconnecting and reconnecting the stream, allowing the new VKEK to be retrieved during the RTSP handshake. Otherwise, screen tearing issues may occur. However, the disconnect-reconnect process takes several seconds, resulting in a black screen and impacting the user experience. Another approach involves the client obtaining the RTSP playback address while simultaneously calling an API to retrieve the VKEK information, and then using the currently obtained VKEK for video playback. This solution requires the client to establish a socket connection with the SIP server. When changes occur, the user is notified via the socket. The user can either directly retrieve the VKEK from the socket or request the VKEK again after receiving the notification and instruct the player to use the latest VKEK. This approach has issues such as socket information transmission delays, data loss, or abnormal socket disconnections. Furthermore, there is a problem of VKEK being out of sync with the video stream (for example, if the video is real-time, after the change, multiple video frame groups have been received, and there may be a few seconds of screen tearing or playback failure in between).

[0048] Please refer to Figure 2 When the client plays back historical videos, such as those from the previous two days, it needs to obtain the playback addresses from those two days and also retrieve the historical VKEK from the cipher machine. Playing back historical videos presents the following problems:

[0049] (1) It is necessary to obtain a full day's worth of VKEKs because the effective time period of a full day's playback VKEK is not fixed. Only by obtaining a full day's worth of VKEKs can we know the effective time period of a certain VKEK. However, some cipher machines have a limited number of VKEKs that can be obtained, and multiple requests are required to obtain them, which will result in a slow playback of the history. Moreover, users sometimes only watch videos for a certain period of time, which will lead to a waste of resources.

[0050] (2) Some framework designs obtain the first VKEK during playback, and then retrieve the next VKEK when it expires according to the validity period of the VKEK. At this time, precise control is required, and the network stability must be ensured, otherwise problems such as screen tearing will occur.

[0051] In the above solution, the live VKEK and encrypted video stream are not on the same server, resulting in a synchronization issue between the VKEK and the encrypted video. Recording playback requires returning all the VKEKs needed for the day's video, but some key servers cannot query multiple keys at once. Furthermore, media stream recipients may only watch a few minutes, leading to wasted resources. To improve these issues, please refer to... Figure 3 and Figure 4 This application provides a method for synchronously transmitting encrypted video and video key encryption key, including:

[0052] Step 110: After receiving the Invite request carrying the first SDP message from the media stream receiver, the SIP server establishes a media connection between the media server and the media stream sender through a three-way call control.

[0053] The media stream receiver sends an Invite request carrying a first SDP message to a SIP server with security features. The first SDP message includes parameters such as the video source ID, the sender's media stream sequence number, the media stream receiver ID, and the receiver's media stream sequence number. The 's' field in the first SDP message is "Play" to represent real-time on-demand playback, and the message header field carries the Monitor-User-Identity field, which indicates the user's identity information.

[0054] Upon receiving an Invite request, a secure SIP server establishes a media connection between the secure media server and the media stream sender via a three-way call control. The specific process includes:

[0055] S11. The SIP server sends an Invite request to the media server, and the media server returns a successful request response to the SIP server, carrying a third SDP message.

[0056] The SIP server sends an Invite request to a media server with security features. This Invite request does not carry an SDP message. Upon receiving the Invite request from the SIP server with security features, the media server with security features replies with a 200 OK response (indicating a successful request) carrying a third SDP message. This third SDP message describes the IP address, port, media format, and other information that the media server with security features will use to receive media streams.

[0057] S12. The SIP server sends an Invite request carrying the fourth SDP message to the media stream sender, and the media stream sender returns a successful request response carrying the fifth SDP message to the SIP server.

[0058] After receiving a 200 OK response from a media server with security features, the SIP server with security features sends an Invite request carrying a fourth SDP message to the media stream sender. This fourth SDP message is generated based on the third SDP message. Specifically, the fourth SDP message includes the third SDP message, modifies the 's' field to "Play" to represent live streaming on demand, adds a 'y' field to describe the SSRC value, and adds an 'f' field to describe media parameters.

[0059] After receiving an Invite request from a SIP server with security features, the media stream sender replies with a 200 OK response carrying a fifth SDP message, which describes the IP address, port, media format, SSRC field, and other information of the media stream sender.

[0060] S13. The SIP server sends an ACK request carrying the fifth SDP message to the media server and an ACK request without an SDP message to the media stream sender to establish Invite sessions with the media server and the media stream sender, respectively.

[0061] After receiving a 200 OK response from the media stream sender, the SIP server with security features sends an ACK request to the media server with security features. This ACK request carries a fifth SDP message, completing the Invite session establishment process with the media server with security features.

[0062] After receiving a 200 OK response from the media stream sender, the SIP server with security features sends an ACK request to the media stream sender. This ACK request does not carry an SDP message, thus completing the Invite session establishment process with the media stream sender.

[0063] Step 120: After completing the three-way call control, the SIP server adds the SSRC value to the Invite request carrying the first SDP message and forwards it to the media server, which then returns a successful response carrying the second SDP message.

[0064] After completing the three-way call control, the secure SIP server establishes a media connection between the media stream receiver and the secure media server via a B2BUA proxy. Specifically, the SIP server sends an Invite request carrying the first SDP message (i.e., ... Figure 4The Invite request in step 1 is modified by adding an SSRC value and then forwarded to a media server with security features. Upon receiving the Invite request, the media server with security features responds with a 200 OK response, which includes a second SDP message describing the IP address, port, media format, SSRC value, and other information of the media stream sent by the media server with security features.

[0065] Step 130: The SIP server forwards the successful response of the request carrying the second SDP message to the media stream receiver, and forwards the ACK request returned by the media stream receiver to the media server.

[0066] A SIP server with security features will forward a 200 OK response carrying a second SDP message to the media stream receiver. (Most existing solutions include the VKEK in the SDP message at this step and send it to the media stream receiver. When the VKEK changes, the SIP server directly sends the changed VKEK to the media receiver, which may cause the VKEK to be out of sync with the video stream.)

[0067] After receiving a 200 OK response, the media stream receiver replies with an ACK request, completing the Invite session establishment process with the SIP server that has security features.

[0068] Step 140: When the video key encryption key changes, the SIP server sends a message carrying the changed video key encryption key to the media server. The media server then distributes the changed video key encryption key to all distribution encrypted video links of the media stream sender. Each distribution encrypted video link encapsulates the changed video key encryption key into an RTP data packet and sends the RTP data packet to the media stream receiver before the next video key frame is sent, so that the media stream receiver can decrypt the video key frame according to the video key encryption key in the RTP data packet.

[0069] When the VKEK changes, the SIP server sends a message (carrying the changed VKEK) to notify the media server. The media server then distributes the received changed VKEK to all distribution encrypted video links of this media stream sender. Each distribution encrypted video link receives the VKEK and waits for the next video keyframe. Before the next video keyframe is sent, it encapsulates the changed VKEK into an RTP data packet and distributes it. After distribution, the VKEK information for this link is cleared. When the media stream receiver receives the RTP data packet, it parses the RTP data packet to obtain the VKEK information for decryption of subsequent frames.

[0070] The process by which each distributed encrypted video link encapsulates the modified video key encryption key into an RTP data packet includes:

[0071] First, each distribution encrypted video link generates an RTP header based on its distribution index and system timestamp, and then appends a custom packet header, such as 000001xx, to the RTP header.

[0072] Then, a 4-byte length reserve is encapsulated after the RTP header, and the 4-byte length reserve is assigned a value according to the length of the changed video key encryption key. Finally, the changed video key encryption key (hexadecimal data) is concatenated to obtain the encapsulated RTP data packet.

[0073] Sending VKEK along with encrypted video to the media streaming recipient has several advantages:

[0074] 1. Ensure synchronization between the VKEK and the encrypted video data stream. Current technology notifies the media stream receiver of VK changes through a SIP server. However, during the process of the media stream receiver receiving the VK, synchronization with the encrypted video stream cannot be guaranteed. The new encrypted video stream may have been received for several seconds before the VKEK is received for decoding, which can lead to problems such as screen tearing.

[0075] 2. Reduces the development workload for media stream receivers and SIP servers. By using video streams, the development of sockets between SIP servers and media stream receivers is reduced. The SIP server only needs to send the changed VKEK to the media server, and the media server can then send it to all distributed media stream receivers according to the bitrate of the media stream sender, facilitating unified management and promotion.

[0076] 3. Reduce unnecessary risks. SIP servers and media servers are typically deployed on the same server or within the same server cluster. They can directly transmit data over the intranet, resulting in high efficiency and short routing distances. However, media stream receivers vary in their configuration and are separated from either the SIP server or the media server by multiple routes. Therefore, the efficiency between media stream receivers and SIP servers is lower than that between SIP servers and media servers. In poor network conditions, media stream receivers and SIP servers may not be able to maintain real-time communication, posing a risk of disconnection and data loss.

[0077] This application uses the same streaming media server to directly inform the streaming media of the VKEK information received by the SIP server. When distributing the streaming media, the VKEK is encapsulated into an RTP data packet and distributed to all clients viewing this camera before the next keyframe. This solves the problem of the streaming media VKEK being out of sync with the encrypted video stream, reduces the risk of network VKEK transmission failure, and the unified processing by the media server reduces the difficulty of troubleshooting for individual media stream receivers in the later stages. At the same time, it reduces the difficulty of media management and client development, making it easier to promote.

[0078] The above is an embodiment of a method for synchronous transmission of encrypted video and video key encryption key provided by this application. The following is an embodiment of a system for synchronous transmission of encrypted video and video key encryption key provided by this application.

[0079] This application provides an embodiment of an encrypted video and video key encryption key synchronous transmission system, comprising:

[0080] The media stream receiver is used to send an Invite request carrying a first SDP message to the SIP server. The first SDP message includes the video source ID, the sender's media stream sequence number, the media stream receiver ID, and the receiver's media stream sequence number.

[0081] The SIP server is used to establish a media connection between the media server and the media stream sender through a three-way call control; after the three-way call control is completed, the SSRC value is added to the Invite request carrying the first SDP message and forwarded to the media server.

[0082] The media server is used to return a successful response carrying a second SDP message after receiving an Invite request; the second SDP message includes the IP address, port, media format, and SSRC value of the media server sending the media stream.

[0083] The SIP server is also used to forward a successful response to a request carrying a second SDP message to the media stream receiver.

[0084] The media stream receiver is also used to return an ACK request to the SIP server after receiving a successful response to the request, and the SIP server forwards the ACK request to the media server.

[0085] The SIP server is also used to send a message carrying the changed video key encryption key to the media server when the video key encryption key changes.

[0086] The media server is also used to distribute the modified video key encryption key to all distribution encrypted video links of the media stream sender. Each distribution encrypted video link encapsulates the modified video key encryption key into an RTP data packet and sends the RTP data packet to the media stream receiver before the next video key frame is sent, so that the media stream receiver can decrypt the video key frame according to the video key encryption key in the RTP data packet.

[0087] As a further improvement, the SIP server is specifically used for establishing media connections between a media server and a media streamer via three-way call control:

[0088] An Invite request is sent to the media server, which then returns a successful request response to the SIP server, carrying a third SDP message. The third SDP message includes the IP address, port, and media format of the media server receiving the media stream.

[0089] Send an Invite request carrying a fourth SDP message to the media stream sender, and the media stream sender returns a successful response carrying a fifth SDP message to the SIP server; the fourth SDP message is generated based on the third SDP message, and the fifth SDP message includes the IP address, port, media format, and SSRC field of the media stream sent by the media stream sender;

[0090] Send an ACK request carrying a fifth SDP message to the media server and an ACK request without an SDP message to the media stream sender to establish Invite sessions with the media server and the media stream sender, respectively.

[0091] As a further improvement, the process by which each distributed encrypted video link encapsulates the modified video key encryption key into an RTP data packet includes:

[0092] Each encrypted video distribution link generates an RTP header based on its distribution index and system timestamp, and then appends a custom-defined packet header to the RTP header.

[0093] A 4-byte length reserve is encapsulated after the RTP header, and the 4-byte length reserve is assigned a value according to the length of the modified video key encryption key. Then, the modified video key encryption key is concatenated to obtain the encapsulated RTP data packet.

[0094] This application also provides an electronic device, which includes a processor and a memory;

[0095] The memory is used to store program code and transfer the program code to the processor;

[0096] The processor is used to execute the method for synchronous transmission of encrypted video and video key encryption key in the foregoing method embodiments according to the instructions in the program code.

[0097] This application also provides a computer-readable storage medium for storing program code. When the program code is executed by a processor, it implements the method for synchronous transmission of encrypted video and video key encryption key in the aforementioned method embodiments.

[0098] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0099] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such process, method, product, or apparatus.

[0100] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0101] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0102] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0103] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0104] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for executing all or part of the steps of the methods described in the various embodiments of this application through a computer device (which may be a personal computer, server, or network device, etc.). The aforementioned storage medium includes: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, optical disks, and other media capable of storing program code.

[0105] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for synchronously transmitting encrypted video and video key encryption key, characterized in that, include: After receiving an Invite request carrying a first SDP message from the media stream receiver, the SIP server establishes a media connection between the media server and the media stream sender through a three-way call control; the first SDP message includes the video source ID for the video on demand, the sender's media stream sequence number, the media stream receiver ID, and the receiver's media stream sequence number; After completing the three-way call control, the SIP server adds an SSRC value to the Invite request carrying the first SDP message and forwards it to the media server, which then returns a successful response carrying the second SDP message. The second SDP message includes the IP address, port, media format, and SSRC value of the media stream sent by the media server. The SIP server forwards the successful response of the request carrying the second SDP message to the media stream receiver, and forwards the ACK request returned by the media stream receiver to the media server; When the video key encryption key changes, the SIP server sends a message carrying the changed video key encryption key to the media server. The media server then distributes the changed video key encryption key to all distribution encrypted video links of the media stream sender. Each distribution encrypted video link encapsulates the changed video key encryption key into an RTP data packet and sends the RTP data packet to the media stream receiver before the next video keyframe is sent. This allows the media stream receiver to decrypt the video keyframe based on the video key encryption key in the RTP data packet.

2. The method for synchronously transmitting encrypted video and video key encryption key according to claim 1, characterized in that, The SIP server establishes a media connection between the media server and the media streamer through a three-way call control, including: The SIP server sends an Invite request to the media server, and the media server returns a successful request response carrying a third SDP message to the SIP server; the third SDP message includes the IP address, port, and media format of the media stream received by the media server; The SIP server sends an Invite request carrying a fourth SDP message to the media stream sender, and the media stream sender returns a successful request response carrying a fifth SDP message to the SIP server; the fourth SDP message is generated based on the third SDP message, and the fifth SDP message includes the IP address, port, media format, and SSRC field of the media stream sent by the media stream sender; The SIP server sends an ACK request carrying the fifth SDP message to the media server and an ACK request without an SDP message to the media stream sender to establish Invite sessions with the media server and the media stream sender, respectively.

3. The method for synchronously transmitting encrypted video and video key encryption key according to claim 2, characterized in that, The generation process of the fourth SDP message includes: Modify the 's' field in the third SDP message to 'Play', add a 'y' field to describe the SSRC value, and add an 'f' field to describe the media parameters. 'Play' indicates real-time on-demand playback.

4. The method for synchronously transmitting encrypted video and video key encryption key according to claim 1, characterized in that, The process by which each distributed encrypted video link encapsulates the modified video key encryption key into an RTP data packet includes: Each encrypted video distribution link generates an RTP header based on its distribution index and system timestamp, and then appends a custom-defined packet header to the RTP header. A 4-byte length reserve is encapsulated after the RTP header, and the 4-byte length reserve is assigned a value according to the length of the modified video key encryption key. Then, the modified video key encryption key is concatenated to obtain the encapsulated RTP data packet.

5. The method for synchronously transmitting encrypted video and video key encryption key according to claim 1, characterized in that, The encrypted video distribution link sends the RTP data packet to the media stream receiver before the next video keyframe is sent, and then further includes: Distribute encrypted video links and clear the video key encryption key information of the current path.

6. A system for synchronously transmitting encrypted video and video key encryption keys, characterized in that, include: The media stream receiver is used to send an Invite request carrying a first SDP message to the SIP server. The first SDP message includes the video source ID for the video being played, the sender's media stream sequence number, the media stream receiver ID, and the receiver's media stream sequence number. The SIP server is used to establish a media connection between the media server and the media stream sender through a three-way call control; after the three-way call control is completed, the SSRC value is added to the Invite request carrying the first SDP message and forwarded to the media server. The media server is configured to return a successful response carrying a second SDP message after receiving an Invite request; the second SDP message includes the IP address, port, media format, and SSRC value of the media server sending the media stream. The SIP server is also configured to forward a successful request response carrying the second SDP message to the media stream receiver; The media stream receiver is also configured to return an ACK request to the SIP server after receiving a successful response to the request, and the SIP server will forward the ACK request to the media server. The SIP server is also configured to send a message carrying the changed video key encryption key to the media server when the video key encryption key changes. The media server is also used to distribute the modified video key encryption key to all distribution encrypted video links of the media stream sender, and each distribution encrypted video link encapsulates the modified video key encryption key into an RTP data packet, and sends the RTP data packet to the media stream receiver before the next video key frame is sent, so that the media stream receiver decrypts the video key frame according to the video key encryption key in the RTP data packet.

7. The encrypted video and video key encryption key synchronous transmission system according to claim 6, characterized in that, SIP servers are specifically used for establishing media connections between media servers and media streamers via three-way call control: The SIP server sends an Invite request to the media server, and the media server returns a successful request response carrying a third SDP message to the SIP server; the third SDP message includes the IP address, port, and media format of the media stream received by the media server; The SIP server sends an Invite request carrying a fourth SDP message to the media stream sender, and the media stream sender returns a successful request response carrying a fifth SDP message to the SIP server; the fourth SDP message is generated based on the third SDP message, and the fifth SDP message includes the IP address, port, media format, and SSRC field of the media stream sent by the media stream sender; The SIP server sends an ACK request carrying the fifth SDP message to the media server and an ACK request without an SDP message to the media stream sender to establish Invite sessions with the media server and the media stream sender, respectively.

8. The encrypted video and video key encryption key synchronous transmission system according to claim 6, characterized in that, The process by which each distributed encrypted video link encapsulates the modified video key encryption key into an RTP data packet includes: Each encrypted video distribution link generates an RTP header based on its distribution index and system timestamp, and then appends a custom-defined packet header to the RTP header. A 4-byte length reserve is encapsulated after the RTP header, and the 4-byte length reserve is assigned a value according to the length of the modified video key encryption key. Then, the modified video key encryption key is concatenated to obtain the encapsulated RTP data packet.

9. An electronic device, characterized in that, The device includes a processor and a memory; The memory is used to store program code and transmit the program code to the processor; The processor is configured to execute the method for synchronous transmission of encrypted video and video key encryption key as described in any one of claims 1-5, according to the instructions in the program code.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store program code, which, when executed by a processor, implements the method for synchronous transmission of encrypted video and video key encryption key as described in any one of claims 1-5.

Images