Full motion video (FMV) routing in one-way delivery system

Abstract

This disclosure describes systems and methods related to full motion video (FMV) routing in a one-way delivery (OWT) system. The present technology enriches datagrams of a video stream sent from a low-trust side of an OWT system with a globally unique identifier (GUID) that is used as an identifier to determine a particular destination of a high-trust side of the OWT system. The enriched video stream is then transmitted over an OWT system that provides high reliability for the enriched video stream. When the enriched video stream is received at the high trust side, the GUID in the datagram is extracted and used to identify the destination address of the destination device in the high trust computing environment. The video stream is then delivered to a destination device having a corresponding destination address.

Description

BACKGROUND

[0001] In data transfer and communication systems, communication is typically performed in a bidirectional manner. For example, two devices that are in communication exchange data in both directions. This capability allows for acknowledgment or confirmation that data has been properly received and processed. If data is not properly received or processed, such as due to packet loss or data corruption, the receiving device is able to request retransmission of the data. In systems where only unidirectional communication is implemented, there is no such acknowledgment or request for retransmission of data.

[0002] It is with respect to these and other general considerations that aspects disclosed herein have been made. Also, although relatively specific problems can be described below, it should be understood that the examples should not be limited to solving the specific problems identified in the background or elsewhere in this disclosure. SUMMARY

[0003] Examples of the present disclosure describe systems and methods related to full motion video (FMV) routing in a one-way transfer (OWT) system. The OWT system includes a component that restricts data flow through the system in a single direction while providing additional reliability enhancements to help ensure that video streams are properly processed and can tolerate system device failures. For example, the system can include a transmitting computing device that has a light emitter that is limited to transmitting functionality only. The present technology utilizes a globally unique identifier (GUID) to enrich video stream datagrams that are transmitted from a low-trust side of the OWT system, which is used as a kind of identifier to determine a particular destination on a high-trust side of the OWT system. The enriched video stream is then transmitted through the OWT system that provides high reliability for it. When the enriched video stream is received on the high-trust side, the GUID in the datagram will be extracted and used to identify a destination address of a destination device in the high-trust computing environment. The video stream is then delivered to the destination device that has the corresponding destination address. Thus, even where the source device in the low-trust computing environment does not know the destination address, the video stream is still able to be properly routed through the OWT to the high-trust computing environment and within the high-trust computing environment.

[0004] This summary is intended to introduce some concepts in a simplified form, which are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used in limiting the scope of the claimed subject matter. Other aspects, features, and / or advantages of the examples will be apparent from the description set forth herein, and from the claims that follow. BRIEF DESCRIPTION OF DRAWINGS

[0005] Examples are described with reference to the following figures.

[0006] Figure 1 An example one-way transfer (OWT) system for full-motion video routing is depicted.

[0007] Figure 2 An example datagram for a rich video stream is depicted.

[0008] Figure 3 An example fault-tolerant video stream core in a one-way transfer system is depicted.

[0009] Figure 4 An example method for full-motion video routing is depicted.

[0010] Figure 5 is a block diagram illustrating example physical components of a computing device with which aspects of the disclosure can be practiced. DETAILED DESCRIPTION

[0011] One-way transfer system (OWT) refers to a computing system that uses one or more data diodes to ensure that data can only be transferred in one direction through respective computing devices of the computing system. In examples, the data diodes ensure one-way data packet transfer by implementing hardware and / or software components such as a transmit-only network interface card (NIC).

[0012] OWT systems can be used to protect networks or endpoints from outbound data transmissions, malicious inbound data transmissions (e.g., viruses and malware), and cyber attacks. As one example, an OWT system facilitates data transfer between an endpoint in a low-trust computing environment (such as the public Internet or other high-threat environment) and an endpoint in a high-trust computing environment (or a computing environment that is more secure relative to the low-trust computing environment). In this example, the OWT system spans or includes multiple computing environments that are separated by one or more boundaries between the low-trust computing environment and the high-trust computing environment.

[0013] In examples, a high-trust environment can be a system or network in which devices, applications, and users are considered trustworthy and security measures have been taken to establish and maintain that trust. In this type of environment, devices and / or related parties, such as devices, software, and users, are typically authenticated, authorized, and / or adhere to established security policies and best practices. High-trust environments typically have strict access controls, encryption, and monitoring to ensure that trust is maintained and the risk of unauthorized access, data breaches, or other security incidents is minimized. Devices within a high-trust environment can be authorized for access or by other devices based on security technologies implemented by the high-trust environment, such as unique encryption keys, secret information, or other cryptographic techniques. For example, communications sent by a high-trust environment can be considered trustworthy by other computing environments or devices based on the high-trust environment (or its devices) being included in an allow list, such as a list of approved devices and / or computing environments. Alternatively, communications sent by a high-trust environment can be considered trustworthy based on a password or credential provided with the communication. In some examples, devices in a high-trust environment can be accessed or by other devices without authentication. High-trust environments typically do not expose security technologies implemented by the high-trust environment to other computing environments, which can be considered low-trust or untrustworthy environments by the high-trust environment.

[0014] In contrast, a low-trust or untrustworthy environment can be a system or network in which devices, applications, and / or users are not explicitly trusted or in which there is a high risk of unauthorized access or malicious activity. This type of environment can have limited or no security measures in place, or the environment can be connected to a large number of external or unmanaged devices. Alternatively or additionally, a low-trust or untrustworthy environment refers to an environment in which other devices within and / or outside of the low-trust or untrustworthy environment do not consider the devices to be secure or trustworthy. Because security technologies implemented by a high-trust environment are not exposed to a low-trust or untrustworthy environment, the low-trust or untrustworthy environment can not be able to access or communicate with the high-trust environment without performing various authorization and / or authentication steps that devices in the high-trust environment do not need to perform.

[0015] Due to the one-way data transmission of OWT systems, it is not possible to confirm that data transmitted over the one-way transmission line has been received and / or properly processed by the receiving device. In contrast, in a two-way system, a communication protocol such as Transmission Control Protocol (TCP) can be used, where an acknowledgement message can be sent back to the transmitting device. For example, with TCP, when a connection is established between two devices, the two devices exchange a series of messages to synchronize and establish connection parameters. Then, when the transmitting device transmits data, the receiving device returns an acknowledgement (ACK) message to the transmitting device to confirm that it has received the data. If the transmitting device does not receive an ACK within a certain time, the transmitting device will resend the data. For OWT systems, since it is not possible to send communications from the receiving device back to the transmitting device, it is not possible to send such an ACK message. Instead, communication must be done using a one-way communication protocol, such as User Datagram Protocol (UDP). Therefore, there must be a robust system to ensure that data transmitted from the transmitting device is actually received and properly processed by the receiving device. Without such a system, the reliability of the system is significantly reduced.

[0016] Additionally, due to the OWT scenario and the separation of the low-trust environment from the high-trust environment, the source device in the low-trust environment does not have knowledge of the final destination. For example, when it is desired to transmit a video stream from the low-side to a specific destination on the high-side, the low-side device typically does not have knowledge of the actual address of the destination device since the IP address is secret or secret to the low-side device. Therefore, only the devices in the high-trust environment have access to the destination address, and since the routing is effectively blind routing, it becomes particularly difficult to route data from the low-side to the high-side. For example, the video source device knows the address of another intermediate device on the low-side, but the video source does not know the address of the final destination. Furthermore, the intermediate device can not know the final destination address. These challenges are even more acute for real-time video streams that do not have discrete packet lengths (e.g., unknown end times), since the routing must be managed continuously for the entire unknown duration of the video stream.

[0017] The present technology provides a solution to the above problems by modifying or enriching the datagrams of a video stream transmitted from the low-side with a globally unique identifier (GUID) that is also used as an identifier for a specific target device on the high-side. The enriched video stream is then transmitted through the OWT system for which it is provided high reliability. When the enriched video stream is received on the high-side, the GUID in the datagram is extracted and used to identify the destination address of the destination device in the high-trust computing environment. The video stream is then delivered to the destination device with the corresponding source address. Therefore, even though the source device does not know the destination address, the video stream can still be properly routed through the OWT system and then into and transmitted within the high-trust computing environment.

[0018] Figure 1 An example OWT system 100 for full-motion video routing is depicted. As presented, system 100 is a combination of interdependent components that interact to form an integrated whole. The components of system 100 can be hardware components or software components (e.g., application programming interfaces (APIs), modules, runtime libraries), with the software components implemented on and / or executed by the hardware components of system 100. In one example, the components of system 100 are distributed across multiple processing devices or computing systems.

[0019] System 100 represents an OWT system for sending video streams between different computing environments. System 100 includes a first computing environment 101 and a second computing environment 103. In some examples, computing environments 101 and 103 are implemented in a cloud computing environment or other types of distributed computing environments and are subject to one or more distributed computing models / services (e.g., Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS), Function as a Service (FaaS)). In some examples, each environment is a separate network or subnetwork.

[0020] although Figure 1 It is described as a specific combination of computing environments and devices, but the size and structure of the devices and computing environments described herein can vary, and can include more than [other components]. Figure 1 The components described herein may be more or fewer. Furthermore, although the examples given herein are described in the context of OWT systems and data transfer between low-trust and high-trust computing environments, these examples are also applicable to other types of data transfer between computing environments of different (or the same) types and security levels. For example, the first environment 101 may also be referred to as the source environment, and the second environment 103 may be referred to as the destination environment.

[0021] The first environment 101 includes a video source such as a video source 102, such as a source camera 102A or another computing device 102B that generates video data (such as a shared screen, computer-generated video, etc.). The source camera 102A can be any type of camera capable of capturing and streaming video data, such as a drone camera, a security camera, a body camera, etc. The first environment also includes a source video agent 104 (which can be referred to as a low video agent 104 in this example) that accesses or stores a low-side FMV mapping table 114. The video stream is sent from the low video agent through a fault-tolerant OWT core 106, where the video stream is received by a protection device 108 of the second environment 103. The protection device 108 sends the video stream to a destination video agent 110 (which can be referred to as a high video agent 110 in this example) in the second environment 103, which accesses or uses a high-side FMV routing table 116. The high video agent 110 uses the high-side FMV routing table 116 to identify destination addresses of one or more destinations, such as high-side destination devices 112A-E display devices 112A-112E in the second computing environment 103. The high-side destination devices 112A-E can include devices to display the video stream, such as display devices 112A-C, and / or storage devices 122D-E to store the video stream. Other types of destination devices 112 are possible, such as devices to process and / or analyze the received video stream.

[0022] The first computing environment 101 can represent a low-trust computing environment, where devices executing within the computing environment 101 are not trusted by devices executing within the second computing environment 103. In such examples, the first computing environment 101 can be physically separate from the second computing environment 103, such that the first computing environment 101 is in a first physical location (e.g., a region, a building, a room, and / or a server rack), while the second computing environment 103 is in one or more other physical locations. Alternatively, in other examples, the computing environments 101, 103 are both located at the same physical location.

[0023] The video source 102 captures or generates video that is converted into a video stream that can have various formats. For example, the video stream is in a Motion Picture Experts Group (MPEG) - Transport Stream (TS) format. In other examples, the video stream is in a Real-time Transport Protocol (RTP) format, a Real-time Streaming Protocol (RTSP) format, or other similar formats.

[0024] The low video proxy 104 then receives the video stream. The low video proxy 104 is a computer device, such as a server, that processes the received video stream and enriches the video stream. To enrich the video stream, the low video proxy 104 adds additional information to the datagrams of the video stream based on the low-side FMV mapping table 114. The low-side FMV mapping table 114 includes data from users (e.g., customers) or administrators in the second environment 103. For example, when a new source-to-destination (e.g., low-to-high) video stream is requested, a virtual machine is provisioned to receive and process the new video stream on a particular IP address and port (which can be referred to as an ingress IP address and / or ingress port). The GUID of the new video stream, the ingress IP address, and the port can be provisioned in the low-side FMV mapping table 114. The data in the low-side FMV mapping table 114 indicates the particular GUID (also referred to herein as a data stream ID) for each video stream that is to be received by the low video proxy 104. For example, a particular GUID can be assigned for each ingress IP address and port on which a particular data stream is received. The low video proxy 104 then monitors the video source on the assigned port or from the assigned IP address. When a video stream is received on a particular IP address and port, an enriched FMV routing packet for the video stream is generated, including the corresponding GUID in the low-side FMV mapping table 114 and the high-side routing table 116. As discussed further below, the high video proxy 110 uses the GUID to identify a particular endpoint (e.g., the destination device 112). Thus, there is a 1 : 1 : 1 mapping relationship between the endpoint, the video stream, and the GUID.

[0025] Figure 2 An example datagram 200 of an enriched video stream is depicted. Generally, the maximum transmission unit for Ethernet is 1500 bytes. Thus, a UDP datagram 200 of less than 1500 bytes can be generated. In some cases, 28 bytes of the datagram are taken up by IP header information, media access control (MAC) header information, and checksum data, leaving 1472 bytes for the actual payload of the datagram. Video streams are typically formed of packets of uniform size (except possibly the last packet in the stream). For example, in the MPEG-TS standard, TS packets are 188 bytes. Thus, up to 7 TS packets can be incorporated into each datagram 200. In this way, there are 156 bytes of additional data left over in the datagram that are typically empty.

[0026] In the present technology, the otherwise empty space in the datagram is used to include the enriched routing data discussed herein. For example, an FMV routing packet 202 can be incorporated into the datagram 200. The FMV routing packet 202 can be provided as the last set of bytes of the datagram 200 (e.g., the last 18 bytes or 21 bytes of the datagram 200).

[0027] The FMV routing packet 202 includes a GUID or data stream ID, which can be a 16-byte value. All datagrams for a particular video stream include the same GUID to ensure that all packets for the video stream end up being routed to the same destination device for the entire duration of the video stream.

[0028] In some examples, the FMV routing packet 202 also includes a reference number that signals to the high video proxy 110 that the datagram 200 should be processed according to the FMV routing protocol of the present technology. The FMV routing packet 202 can also include a control value that indicates whether the particular datagram 200 is the beginning of a video stream, a middle portion of the stream, or the end of the stream (e.g., the last datagram of the stream). In some examples, this control value is 1 byte in the form of 8 flag bits.

[0029] In some examples, rather than inserting an additional FMV routing packet 202 into the datagram 200, the null packet of the datagram is modified to incorporate the routing data of the FMV routing packet. For example, in some protocols, such as MPEG-TS, null packets are a particular type of packet that are utilized for different purposes, such as padding or bit rate maintenance. For example, in streaming applications, a consistent bit rate is desired, and null packets help maintain this bit rate by padding any gaps that arise due to changes in encoded content. While these null packets contain data to maintain the bit rate (e.g., all ones), this data is essentially meaningless. Thus, in examples of the technology disclosed herein, the data of the null packet is replaced with the routing data discussed herein. The null packet itself also has a consistent identifier that identifies the particular packet as a null packet. For example, the packet identifier (PID) of a null packet can always be 8191. Thus, on the destination side, the null packet can be easily identified, and an initial inspection of the null packet indicates whether it is a traditional null packet or a null packet that has been modified to incorporate the routing data discussed herein.

[0030] Returning to Figure 1 Once the low video proxy 104 generates the enhanced datagrams for the video stream, the enhanced datagrams are sent to the fault-tolerant OWT core 106. For example, the low video proxy 104 can route the enhanced datagrams to a particular IP address or port of the fault-tolerant OWT core 106. As long as the low video proxy 104 continues to receive the video stream, the low video proxy 104 continues to generate enhanced datagrams. As used herein, the set of enhanced datagrams can be referred to as an enriched video stream.

[0031] The fault-tolerant OWT core 106 receives the enriched video stream and sends it to the protection device 108. The operation of the fault-tolerant OWT core 106 will be described below with reference to Figure 3An example of the fault-tolerant OWT core 106 is discussed in more detail. The protection appliance 108 protects the second computing environment 103 from data entering the second computing environment 103 from the first computing environment 101. The protection appliance 108 performs changes and / or checks on the enriched video stream. For example, the protection appliance 108 can transcode the enriched video stream. Alternatively or additionally, the protection appliance 108 performs security checks or policy enforcement on the video stream to remove malicious data or remove any other type of data, according to a policy set by an administrator of the second computing environment 103. For example, the protection appliance 108 performs pattern enforcement on the data, such as enforcing a pattern of a particular video stream format. If the enriched video stream complies with the criteria set by the protection appliance 108, the protection appliance 108 further sends the enriched video stream to the high video proxy 110.

[0032] The protection appliance 108 can have a fixed set of video lanes, and each graphics processing unit (GPU) of the protection appliance 108 can have approximately 10 video lanes. A given video lane can have a static input port and a static destination. The static input port receives a particular video stream, and that particular video lane can continue to process that video stream for the duration of the video stream. The static destination of all video lanes of the protection appliance 108 can be one or more ports of the high video proxy 110, such that all video streams from the protection appliance 108 are provided to the high video proxy 110. Thus, the protection appliance 108 itself does not need to know or determine the final destination of the video stream in the second environment 103. Rather, as discussed below, the high video proxy 110 uses in-band metadata (e.g., FMV routing packets 202) and application logic to finally route the video stream to its final destination.

[0033] The high video proxy 110 inspects the datagrams 200 of the enriched video stream to identify the FMV routing packet 202 in each datagram. The high video proxy 110 then extracts the data of the FMV routing packet 202, including the GUID. The high video proxy 110 then accesses the high-side FMV routing table 116 to determine the IP address or port of the destination device(s) 112 for the video stream. For example, the high video proxy 110 can utilize the GUID to perform a lookup operation or query on the high-side FMV routing table 116, which returns one or more destination addresses.

[0034] The TS packets of the datagram are then sent by the high video proxy 110 to the destination device(s) 112. Enhancements made to the video stream by the low video proxy 104 can be removed by the high video proxy 110, or alternatively left in place for the purposes of downstream routing. For example, in some examples, the FMV routing packets 202 are removed from the video stream, and the un-enriched video stream is delivered to the destination device(s) 112, which are identified from the high-side FMV routing table 116 based on the GUID. Sending the video stream can include sending the TS packets to the identified IP address and / or from the identified port. Since the high video proxy 110 and the destination device(s) 112 are located in the same second environment 103, bi-directional communication such as TCP can be used to send the video stream from the high video proxy 110. The destination device(s) 112 then display, store, and / or process the real-time video stream for the duration of the video stream.

[0035] The above examples leverage otherwise blank space in the datagram to incorporate routing information, which provides an efficient routing solution that limits additional bandwidth and generally reduces latency. The above examples also provide the advantage of providing routing information in a way that does not alter the video stream itself and preserves the unidirectional directionality of the OWT system, as compared to other potential solutions to the blind routing problem.

[0036] For example, another potential solution to the blind routing problem includes inserting routing data into the video stream itself. For example, MPEG-TS streams are generally composed of a series of packetized elementary streams (PES), such as different audio, video, and data streams, which are multiplexed together to form a transport stream. In some examples, the data stream can include data such as key length value (KLV) data, among others. To include routing metadata in the transport stream, a new PES can be generated and incorporated into the transport stream. However, the additional complexity of this solution can increase latency, and can increase the risk of inadvertently modifying or interfering with the original data of the video stream. In contrast, the FMV routing techniques discussed herein, such as with respect to Figures 1-2 the FMV routing packets 202, allow for the inclusion of routing information without interfering or modifying the actual video stream itself.

[0037] As another possible solution to the blind routing problem, out-of-band routing data can be exchanged between devices in the first environment 101 and the second environment 103. However, this exchange of routing data requires a two-way communication scheme. While a secure channel can be created to allow such data, this two-way channel still increases the risk of the second environment 103. Additionally, additional computing resources are needed to support such a channel. In contrast, the FMV routing techniques discussed herein provide in-band metadata within datagrams to provide routing information. However, in examples where such in-band metadata cannot be achieved for some reason, both solutions of modifying the data stream or using out-of-band techniques can be utilized.

[0038] Figure 3 An example fault-tolerant video streaming core 300 in a unidirectional transfer system is depicted. In the depicted example, the core 300 is an example system that includes Figure 1 the fault-tolerant OWT core 106 and the protection device 108 of the system 100.

[0039] Figure 3 The first computing environment 301 and the second computing environment 303 are again presented. In the depicted example, the first computing environment 301 includes a computing device 308. The computing device 308 can be referred to herein as a low-side computing device 308 or a sending device 308. The low-side computing device 308 receives the enriched video stream 310 from a low-side proxy (not depicted) in the first computing environment 301. The low-side computing device 308 can use a file splitting service or utility to separate the enriched video stream 310 into one or more data chunks, thereby serializing the enriched video stream 310, which can be implemented locally to the computing device 308 or can be accessed remotely by the computing device 308. Figure 3

[0040] The segmented data of the enriched video stream 310 is then unidirectionally sent (e.g., optically) to the second computing environment 303. The second computing environment 303 includes a computing device 312 and a computing device 314. In some examples, the computing devices 312 and 314 are located proximate to the computing device 308 (e.g., within the same building or room). For example, the computing devices 312, 314, and the computing device 308 can be located within the same room of a data center, such that the computing device 308 is located in a first data rack (e.g., a server rack or data cabinet) and the computing devices 312, 314 are located in a second data rack or a different rack than the first data rack. In these examples, the computing device 308 and the computing devices 312, 314 can be directly connected via point-to-point cabling, which can be fiber optic, as discussed further herein.

[0041] ​In some examples, computing devices 312 and 314 are also physically separated from each other to help ensure reliability and redundancy. For example, computing devices 312 and 314 can be in different server racks, different rooms, or different buildings, and rely on different power sources. Thus, if computing device 312 loses power, second computing device 314 can still be powered. In other examples, computing devices 312 and 314 are located at a location remote from computing device 308 (e.g., in a different building or room).

[0042] Computing devices 312, 314 receive the enriched video stream sent from low-side computing device 308. Thus, in some examples, computing device 312 can be referred to herein as a first receiving device 312, and computing device 314 can be referred to herein as a second receiving device 314. Receiving devices 312, 314 can also operate as protection devices, and computing devices 312, 314 can also be referred to as first and second protection devices 312, 314, or cross-domain protection devices 312, 314.

[0043] Returning to the data transmission between low-side computing device 308 and protection devices 312, 314, the one-way data transfer from low-side computing device 308 to protection devices 312, 314 can be implemented optically. Using light for transmission improves the speed, reliability, and / or security of the data transfer. In the depicted example, low-side computing device 308 includes an optical transmitter 309 that converts the segmented data of enriched video stream 310 into an optical signal that is sent into first optical fiber 311. For example, optical transmitter 309 can encode the segmented data of video stream 310 into a series of light pulses.

[0044] Generally, fiber-optic communication is a method of sending information from one location to another using optical signals sent through an optical fiber. Optical fibers are typically thin glass or plastic wires that are designed to guide light along their length. Optical fibers provide a number of advantages, including high speed and little loss in signal strength when sending data. Additionally, fiber-optic communication is more secure than other forms of communication because signals sent through optical fibers are difficult to intercept and tamper with.

[0045] The optical transmitter 309 can be a transmit-only NIC or other portion of a circuit board that includes only transmit functionality. For example, the circuit board can not have the ability to receive optical data. In other examples, if the circuit board includes an optical receiver, neither of the optical fibers from one of the protection devices 312 and 314 is connected to the receiver, so the optical receiver cannot receive any data. For example, a transmit-only NIC sends data to an endpoint, but cannot receive data from the endpoint because the receive pins on the network controller chip of the transmit-only NIC are physically cut off. In some examples, the transmit-only NIC also includes firmware that sets the link state of the transmit-only NIC to always be "up" (e.g., enabled and / or active). In other examples, a transmit-only circuit can be formed by attaching a splitter cable (e.g., a Y-splitter cable), where the transmit signal is split into two cables, one of which is directed back to the optical receiver of the transmitter circuit, thereby establishing a first layer link state, and causing the circuit to sense a return data path, even though there is no return data path in actuality. In other examples, a field programmable gate array (FPGA) or similar device can be configured to limit the data stream to be unidirectional (e.g., transmit-only). When a physical component (rather than a software-defined constraint) requires unidirectional communication, the unidirectional communication is considered to be physically mandated.

[0046] The optical signal generated from the optical transmitter 309 is subsequently split by the splitter 317. The splitter 317 splits the optical signal (e.g., the light transmitted through the first optical fiber 311) into multiple optical signals. In the depicted example, the optical signal is split into two divided optical signals. One of the divided optical signals is passed into the first receiving optical fiber 319, while the other divided optical signal is passed into the second receiving optical fiber 321. Each of the divided optical signals replicates the original optical signal, and thus includes the same sample data as the original optical signal. While the optical signal is split into two optical signals in this example, in different examples, the optical signal can be split into additional signals.

[0047] In some examples, the splitter 317 is a passive splitter that does not require a power supply. For example, when light enters the splitter 317 from the first optical fiber 311, the light is split into the first receiving optical fiber 319 and the second receiving optical fiber 321 without the need for additional power. The passive splitter 317 utilizes the reflective and / or refractive properties of its materials to split the light, such as by using two glass prisms that are bonded or otherwise connected to each other to create partially reflective surfaces, half-silvered mirrors, dichroic mirror prisms, or other suitable designs for splitting a beam of light.

[0048] By utilizing a passive beam splitter 317, additional reliability can also be brought to the system as the passive beam splitter 317 operates without the need for power. However, in other examples, an active or powered beam splitter 317 can be used. In some examples, the beam splitter 317 is positioned within the first computing environment 301 or the second computing environment 303. For example, the beam splitter 317 can be part of the low-side computing device 308 and / or part of the light emitter 309. In other examples, the beam splitter 317 is positioned in the second computing environment 303. For example, the beam splitter 317 can be incorporated into the protection device 312, the second protection device 314, and / or another device of the second computing environment 303.

[0049] While the beam splitter 317 is primarily discussed herein as a passive beam splitter, the beam splitter 317 can include other devices for splitting and / or duplicating optical signals, and in some examples, the beam splitter 317 can also be powered by a power source. For example, the beam splitter 317 can include a switch with a switched port analyzer (SPAN) port. The SPAN port creates a copy or duplicate of data that is then sent to another destination. Thus, the SPAN port can also be referred to as a mirror port in some examples. The duplicate is created by monitoring a source port and copying the data received on the source port. The beam splitter 317 can also take the form of a test access point (TAP). A TAP is a passive hardware device that splits an optical signal into two independent paths via a beam splitter or a passive optical coupler, thereby splitting or duplicating the data.

[0050] The split optical signals are then received by the first protection device 312 and the second protection device 314 in parallel, respectively. More particularly, the split optical signal propagating through the first receiving optical fiber 319 is received by the first optical receiver 313 of the first protection device 312 coupled with the first receiving optical fiber 319. The split optical signal propagating through the second receiving optical fiber 321 is received by the second optical receiver 315 of the second protection device 314 coupled with the second receiving optical fiber 321. The optical receivers 313, 315 convert the optical signals into electrical data signals that are substantially identical to the electrical signals representing the segmented data of the video stream 310 provided to the light emitter 309. The electrical data signals representing the segmented data of the video stream 310 can then be processed by the first protection device 312 and the second protection device 314 as discussed herein. In effect, the duplicated, enriched video stream is thus received by the protection devices 312 and 314.

[0051] If the first protection device 312 determines that the enriched video stream 310 meets the requirements of the second computing environment 303 (as discussed above), the first protection device 312 transcodes and sends the enriched video stream to the first landing device 318. Similarly, if the second protection device 314 determines that the enriched video stream meets the requirements of the second computing environment, the second protection device 314 sends and transcodes the video stream to the second landing device 320. Thus, if both protection devices 312 and 314 are functioning properly and sending the enriched video stream 310, the landing devices 318 and 320 receive a replicated video stream 310.

[0052] Because the enriched video stream 310 sent from the first computing environment 301 to the second computing environment 303 is in a unidirectional manner, there is no way to transmit back to the first computing environment 301 an acknowledgement or a request to resend the video stream (or portions thereof) from the second computing environment 303. For example, if the first protection device 312 or the first landing device 318 stops operating (e.g., system crash, power outage), the low-side computing device 308 will not be able to determine that the device is no longer functioning properly. To help ensure that the video stream received by the second computing environment 303 is treated and processed with high fidelity, the second protection device 314 and the second landing device 320 provide data redundancy to the first protection device 312 and the first landing device 318 for the video stream 310 transmitted from the first computing environment 301 to the second computing environment 303. Thus, even if one of the protection devices 312 or 314 (and / or one of the first landing device 318 or the second landing device 320) fails, the other device is still able to process the video stream 310.

[0053] To provide this data redundancy, the first landing device 318 and the second landing device 320 can communicate with each other, which can be bidirectional communication (e.g., TCP) or unidirectional communication depending on the particular implementation. In an example, the data communicated is referred to as performance data 316.

[0054] The performance data 316 indicates performance and / or status of the particular device from which the data is transmitted, and / or data about the video stream being processed. For example, the performance data 316 from the first landing device 318 indicates the status or performance of the first landing device 318. The performance data 316 from the second landing device 320 indicates the status or performance of the second landing device 320. In some examples, the performance data 316 also provides status data about the respective protection device. For example, the performance data 316 from the first landing device 318 can also indicate operational status data of the first protection device 312. The performance data 316 can also include operational status data of the second protection device 314. Thus, based on the status data 316, each of the first landing device 318 and the second landing device 320 is able to determine whether the other device is functioning properly.

[0055] The first landing device 318 and / or the second landing device 320 use the performance data 316 to change its operational status, and determine which of the first landing device 318 or the second landing device 320 is the source of the enriched video stream 310 provided to the high video proxy 325.

[0056] In some examples, the performance data 316 includes information such as time of normal operation, processing speed, bandwidth utilization. Alternatively or additionally, the performance data 316 can include transmission information for one or more time periods. Examples of transmission information include: amount of data transmitted during the time period, a list of data chunks, segments, or packets transmitted for the video stream, a data transmission metric (e.g., average or maximum time to transfer a video stream packet), number of packets lost during transmission, and current role or operational status of a computing device (e.g., primary or secondary device).

[0057] The performance data 316 can also include data specific to the enriched video stream 310 being processed by the first landing device 318 and the second landing device 320. For example, the performance data 316 can include data based on a continuity counter for the video stream 310. A continuity counter is a mechanism used in video stream transmission to ensure proper ordering and consistency of data packets when transmitted over a network. For example, one example of a continuity counter can be used with MPEG-TS format.

[0058] For video streams in MPEG-TS format, the continuity counter is a 4-bit field in the header of each transport stream packet (TSP). For each consecutive packet carrying a payload belonging to the same packetized elementary stream (PES), the counter is incremented by 1, PES representing a single video, audio, or data stream within the transport stream. The continuity counter provides a way to identify and manage packet loss, duplication, or reordering that can occur during transmission. In some examples, the counter is incremented between 1-16, and then reset to 1 for the next packet. In the present technology, the first landing device 318 and the second landing device 320 can also create a secondary counter that indicates which set of continuity counters is being received. Then, the first set of 16 counts / packets can be distinguished from the second set (and other subsequent sets) of 16 counts / packets.

[0059] As some additional details, when the video stream 310 is initially encoded in the first computing environment 301, the video stream 310 is broken into smaller chunks and encapsulated into transport stream packets (TSPs) for transmission. Each TSP has a header that contains information about the packet, such as a packet identifier (PID) that uniquely identifies the PES to which the packet belongs and a continuity counter that tracks the sequence of packets within the PES. As the packets are transmitted, the continuity counter in the TSP header is incremented for each consecutive packet that belongs to the same PES.

[0060] The first landing device 318 and the second landing device 320 can check the continuity counter of each received TSP. If the counter value is in the expected order, the first landing device 318 and the second landing device 320 can assume that the packet arrived in the correct order, without loss or duplication. If the continuity counter values are out of order, the first landing device 318 and the second landing device 320 can detect packet loss, duplication, or reordering.

[0061] The results of the first landing device 318 and / or the second landing device 320 analysis of the continuity counter can be included in the performance data 316. In some examples, the continuity counter for each packet processed by the first landing device 318 and / or the second landing device 320 is included in the performance data 316. For example, when the first landing device 318 processes a particular packet, the performance data 316 can indicate the continuity counter value for that packet to indicate that the packet has been processed by the first landing device 318.

[0062] In some examples, the first landing device 318 and the second landing device 320 can operate as a primary device or a secondary device. The primary device further sends video data 310 through the system, such as to the high video proxy 325. The secondary device does not further send received data through the system. For example, the secondary device can eventually discard (e.g., delete or drop) its received video stream data. In other examples, the secondary device stores a copy of the video stream 310 for backup or recovery.

[0063] The designation of the first landing device 318 or the second landing device 120 as a primary device or a secondary device depends on the performance data 316. In some examples, one of the landing devices 318 and 320 can be designated as the primary device for all incoming video streams until the performance data 316 indicates that the primary device is no longer functioning properly. For example, the first landing device 318 can initially be designated as the primary device, while the second landing device 320 can be designated as the secondary device.

[0064] In this example, the first landing device 318 maintains its primary device operational status until the second landing device 320 is no longer functioning or is no longer functioning properly. The criteria for determining whether the first landing device 318 is functioning properly can be based on performance metrics for the first landing device 318, which can be represented in the performance data 316. For example, health data and / or send information can be compared to one or more thresholds to determine whether the first landing device 318 is functioning properly or within acceptable limits. If performance data 316 is not received (e.g., due to the first landing device 318 being down), the performance data 316 can be considered to be outside of the threshold, thus indicating that the first landing device 312 is not functioning properly. The second landing device 320 can make this determination based on the performance data 316 received from the first landing device 318. Additionally or alternatively, the second landing device 320 determines that the first landing device 318 is not functioning properly if the second landing device 320 does not receive performance data 316 from the first landing device 318 for a timeout period (e.g., a set duration of time).

[0065] When the second landing device 320 determines that the first landing device 318 is not functioning properly based on the performance data 316 (or lack thereof), the second landing device 320 changes its operational status from a secondary device to a primary device and becomes the source of the video stream 310 to subsequent devices, such as the high video proxy 325. If the first landing device 318 is still partially operational, the second landing device 320 can indicate the operational status change to the first landing device 312 as part of the performance data 316. When the second landing device 320 operates as a primary device, the second landing device 314 further sends the video stream through the system (e.g., to the high video proxy 325), while the first landing device 318 no longer sends data.

[0066] When the second landing device 320 operates as the primary device, the second landing device 320 can continue to send performance data 316 to the first landing device 318. In examples in which the first landing device 318 is still operating (but with degraded performance), the first landing device 318 can also continue to send performance data 316 to the second landing device 320. In some examples, the second landing device 320 continues to operate as the primary device even if the first landing device 318 regains its normal or acceptable performance (as indicated by the performance data 316). In such examples, the first landing device 318 can transition back to the primary device when the performance data 316 indicates that the second landing device 320 is no longer functioning properly. The determination that the second landing device 320 is not functioning properly can be similar to the determination that the first landing device 318 is functioning properly discussed above. For example, the first landing device 318 can compare the performance data 316 from the second landing device 320 to one or more thresholds to determine whether the second landing device 320 is functioning properly.

[0067] In other examples, the second landing device 320 can revert to the secondary device upon detecting that the first landing device 318 regains functionality. The first landing device 318 then continues its operating state as the primary device. For example, based on the performance data 316, the second landing device 320 can determine that the first landing device 318 has recovered normal functionality. The second landing device 320 can then send a message (e.g., as part of the performance data 316) indicating that the first landing device 318 will resume operating as the primary device and that the second landing device 320 is switching its operating state to the secondary device.

[0068] The switching of operating states can occur quickly, and in some examples, the switching can be completed in less than 100 milliseconds (ms). In some examples, the switching occurs on a packet-by-packet basis. For example, if the second landing device 320 operates as the secondary device and receives a particular TS packet with a particular continuity count value, and the performance data 316 indicates that the first landing device 318 did not process the particular packet, the second landing device 320 sends the particular packet. The sending of the particular packet can then be indicated in the performance data 316. The first landing device 318 can maintain its operating state as the primary device to process subsequent packets, or the second landing device 320 can switch to the primary device to process subsequent packets until another packet occurs that is processed by one landing device but not the other.

[0069] In some examples, the landing devices 318 and 320 do not change operational state. Instead, both landing devices 318 and 320 can send the replicated enriched video stream to the switching device 323. The performance data 316 from each of the landing devices 318 and 320 can also be provided to the switching device 323. The switching device 323 then switches between the primary enriched video stream (e.g., the enriched video stream from the first landing device 318) and the secondary enriched video stream (e.g., the enriched video stream from the second landing device 320) and provides a single enhanced video stream to the high video proxy 325.

[0070] The switching device 323 effectively treats the replicated video streams 310 from the first landing device 318 and the second landing device 320 as a primary video stream and a secondary video stream. The primary video stream is provided to the high video proxy until a disruption in the primary video stream is detected. When a disruption is detected, the secondary video stream is sent to the high video proxy 325.

[0071] The disruption in the primary video stream can be based on a continuity counter of the video stream and / or a continuity counter from the performance data 316. For example, when an expected packet of the video stream 310 is not received as part of the primary video stream, the switching device 323 can quickly switch to the secondary video stream and provide the secondary video stream to the high video proxy 325. The switching device 323 can continue to provide the secondary video stream to the high video proxy 325 until the switching device 323 detects a disruption in the secondary video stream. When a disruption in the secondary video stream is detected, the switching device 323 switches back to the primary video stream. Because the switching device 323 receives both the primary video stream and the secondary video stream, the switching device 323 switches to the video stream with the least disruption or the least number of dropped packets. The switching between the primary video stream and the secondary video stream can be performed quickly (e.g., 100 milliseconds or less). For example, in some examples, the switching is performed on a packet-by-packet basis.

[0072] The switching between the primary video stream and the secondary video stream can also be based on the performance data 316, such as health data of the first landing device 318 or the second landing device 320. For example, if the performance data 316 indicates that the first landing device 318 is experiencing degraded performance, the switching device 323 can switch to the secondary video stream even if the primary video stream has not experienced any disruption.

[0073] Figure 4 An example method 400 for full motion video routing is depicted. The method 400 can be performed by one or more devices discussed above, such as Figures 1-3 one or more devices shown in FIG. 4.

[0074] At operation 402, real-time video stream data is received by a low video proxy in a low trust environment. The real-time video stream can be received from a camera in the low trust environment.

[0075] At operation 404, the low video proxy accesses an FMV mapping table, which includes GUIDs for different streams received at specific source addresses or on specific ports. The low video proxy identifies the GUID for the received video stream based on the address of the video stream or the port on which the video stream is received by the low video proxy.

[0076] At operation 406, the low video proxy generates augmented datagrams, each including a video packet from the video stream and a routing packet including the GUID identified at operation. For example, when the video stream is an MPEG-TS stream, the datagrams can include 7 TS packets and one FMV routing packet including the GUID. The FMV routing packet can include additional information or data as discussed above. In some examples, instead of adding an additional FMV routing packet to the datagrams, the null packets of the datagrams can be modified to include the GUID and other routing data as discussed above. At operation 408, the enriched video stream formed by the augmented datagrams is sent to a high video proxy in a high trust environment through an OWT system, such as system 300 in Figure 3

[0077] At operation 410, the high video proxy receives the enriched video stream. At operation 412, for the datagrams of the enriched video stream, the high video proxy extracts the routing metadata including the GUID. Extracting the metadata can include identifying the FMV routing packet in the datagrams received by the high proxy. The FMV routing packet can be identifiable as a last preset number of bytes (e.g., 18, 21) in the datagram. When the routing data (e.g., GUID) is included in a null packet, the null packet can be identified via its PID (e.g., 8191).

[0078] At operation 414, based on the extracted GUID and the FMV routing table, a destination address (e.g., IP address or port) for the video stream is identified. For example, the high video proxy can query the FMV routing table with the extracted GUID and, in response to the query, receive the destination address(es) for the destination device(s) for the video stream. At operation 416, the high video proxy sends the video stream (without the metadata inserted by the low video proxy) to the destination device(s) having the destination address(es).

[0079] Figure 5 ​is a block diagram illustrating physical components (e.g., hardware) of a computing device 500 with which aspects of the present disclosure can be practiced. The computing device components described below can be suitable for the computing devices and systems described above, such as a video proxy, a protection device, a landing device, a switching device, etc. In a basic configuration, computing device 500 includes at least one processing unit 502 and system memory 504. Depending on the configuration and type of computing device, system memory 504 can comprise volatile storage (e.g., random access memory, RAM), non-volatile storage (e.g., read-only memory, ROM), flash memory, or any combination.

[0080] System memory 504 includes operating system 505 and one or more program modules 506 suitable for operation software application 520, such as one or more components of the system support described herein. For example, operating system 505 can be suitable for controlling the operation of computing device 500.

[0081] Furthermore, embodiments of the disclosure can be practiced in conjunction with a graphics library, other operating systems, or any other application program and is not limited to any particular Figure 5 application or system. This basic configuration is illustrated in Figure 5 by those components within dashed line 508. Computing device 500 can have additional features or functionality. For example, computing device 500 can also include additional data storage devices (removable and / or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated in

[0082] As stated above, a number of program modules and data files can be stored in system memory 504. While executing on processing unit 502, programs modules 506 (e.g., application 520) can perform processes including aspects, as described herein. Other program modules that can be used with aspects of the present disclosure can include electronic mail and contacts applications, word processing applications, spreadsheet applications, database applications, slide presentation

[0083] application 525 that performs the operations discussed herein. Moreover, embodiments of the disclosure can be practiced with other computer system configurations, including a standalone computer system configured to execute the various software components at a single location, a multi-computer system configured to Figure 5Each or many of the illustrated components can be integrated onto a single integrated circuit. Such a SOC device can include one or more processing units, graphics units, communications units, system virtualization units, and various application functionality all as an integrated circuit on a single chip substrate. When operating via the SOC, the functionality described herein with respect to the capabilities of the client switching protocol can be operated via application-specific logic integrated with other components of the computing device 500 on the single integrated circuit (chip). Embodiments of the disclosure can also be practiced using other technologies capable of reconfiguring executing logic (e.g., such as "and," "or," "not" as well as other technologies including mechanical, optical, fluidic, and quantum technologies. In addition, embodiments of the disclosure can be practiced within a general computer system or in any other circuit or system.

[0084] The computing device 500 can also have one or more input device(s) 512 such as a keyboard, a mouse, a pen, a sound or voice input device, a touch or swipe input device, etc. Output device(s) 514 such as a display, speakers, a printer, etc. can also be included. The aforementioned devices are by way of example and other devices can be used. The computing device 500 can include one or more communication connections 516 allowing communication with other computing devices 518. Examples of suitable communication connections 516 include radio frequency (RF) transmitter, receiver, and / or transceiver circuitry; universal serial bus (USB), parallel, and / or serial ports.

[0085] The term "computer readable media" as used herein can include computer storage media. Computer storage media can include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, or program modules. The system memory 504, the removable storage device 509, and the non-removable storage device 510 are all computer storage media examples (e.g., memory storage). Computer storage media can include RAM, ROM, electrically erasable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other article of manufacture which can be used to store information and which can be accessed by the computing device 500. Any such computer storage media can be part of the computing device 500. Computer storage media does not include a carrier wave or other propagated or modulated data signal.

[0086] Communication media can be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media. The term "modulated data signal" can describe a signal that has one or more characteristics set or changed in such a manner as to encode information in the signal. For example, communication media can include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency, infrared, and other wireless media.

[0087] In one aspect, the technology relates to a system for routing a video stream in an one-way transfer (OWT) system. The system includes a source video proxy in a source computing environment that receives a video stream on an ingress port at an ingress Internet Protocol (IP) address, accesses a mapping table storing a unique identifier for the video stream based on a corresponding ingress IP address and port of the video stream, identifies the unique identifier for the video stream based on the ingress port and IP address of the video stream, generates an enhanced datagram that includes video packets of the video stream and routing metadata including the unique identifier, where the enhanced datagram forms an enriched video stream, and sends the enriched video stream through the OWT system. The system also includes a destination video proxy in a destination computing environment secured by the OWT system that receives the enriched video stream, extracts the unique identifier from the routing metadata of the enhanced datagram of the enriched video stream, identifies a destination address for the video stream from a routing table storing corresponding destination addresses for a plurality of unique identifiers based on the extracted unique identifier, and sends the video stream to a destination device having the destination address.

[0088] In an example, the video stream sent from the destination video proxy does not include the routing metadata added by the source video proxy. In another example, the source computing environment is a low trust environment and the destination computing environment is a high trust computing environment. In another example, the enhanced datagram includes up to seven TS packets and a routing packet including the routing metadata. In yet another example, the routing packet also includes a reference number and control data indicating whether the enhanced datagram is a start of the video stream, a middle of the video stream, or an end of the video stream. In yet another example, the routing packet is a modified null packet.

[0089] In another aspect, the technology relates to a method of routing a video stream in an one-way transfer (OWT) system. The method includes receiving, by a source video agent in a source computing environment, a video stream having a source address; identifying, by the source video agent, a unique identifier for the video stream based on the source address of the video stream; generating, by the source video agent, an enhanced datagram that includes a video packet of the video stream and routing metadata that includes the unique identifier, wherein the enhanced datagram forms an enriched video stream; sending, by the source video agent, the enriched video stream through the OWT system; receiving, by a destination video agent in a destination computing environment, the enriched video stream; extracting, by the destination video agent, the unique identifier from the routing metadata of the enhanced datagram of the enriched video stream; identifying, by the destination video agent, a destination address of the video stream based on the extracted unique identifier; and sending, by the destination video agent, the video stream to a destination device having the destination address.

[0090] In an example, identifying, by the source video agent, the unique identifier includes accessing a mapping table that stores unique identifiers for video streams based on corresponding ingress IP addresses and ingress ports of the video streams, and identifying the unique identifier for the video stream based on the ingress address and the ingress port of the video stream. In another example, identifying, by the destination video agent, the destination address includes accessing a routing table that stores corresponding destination addresses for a plurality of unique identifiers, querying the routing table with the unique identifier, and receiving the destination address in response to the query. In yet another example, the video stream sent from the destination video agent does not include the routing metadata added by the source video agent. In still another example, the destination video agent receives the enriched video stream from a protection device that protects the destination computing environment. In yet another example, the routing metadata is in a modified null packet.

[0091] In another example, the enhanced datagram includes seven TS packets and a routing packet that includes the routing metadata. In another example, the routing packet further includes a reference number and control data that indicates whether the enhanced datagram is a start of the video stream, a middle of the video stream, or an end of the video stream.

[0092] In another aspect, the technology relates to a method of routing a video stream in an one-way transfer (OWT) system. The method includes receiving, by a destination video agent in a destination computing environment, an enriched video stream that includes an enhanced datagram that includes a video packet of the video stream and routing metadata that includes a unique identifier; extracting, by the destination video agent, the unique identifier from the routing metadata of the enhanced datagram of the enriched video stream; identifying, by the destination video agent, a destination address of the video stream based on the extracted unique identifier; and sending, by the destination video agent, the video stream to a destination device having the destination address.

[0093] In an example, the enriched video stream is generated by a source video proxy that receives the video stream having a source address, and the source video proxy identifies the unique identifier by accessing a mapping table that stores unique identifiers for video streams based on source addresses of the video streams, and identifying the unique identifier for the video stream based on the source address of the video stream. In another example, identifying the destination address by the destination video proxy includes accessing a routing table that stores corresponding destination addresses for a plurality of unique identifiers, querying the routing table with the unique identifier, and receiving the destination address in response to the query. Yet another example, the video stream is in Motion Picture Experts Group (MPEG) - Transport Stream (TS) format. In another example, the enhancement datagram includes up to seven TS packets and a routing packet that includes routing metadata. In yet another example, the routing packet further includes control data that indicates whether the enhancement datagram is a beginning of the video stream, a middle of the video stream, or an end of the video stream.

[0094] For example, aspects of the disclosure are described above with reference to block and / or operational diagram illustrations of methods, systems, and computer program products in accordance with aspects of the present disclosure. The functions / acts noted in the blocks can occur out of the order noted in any flowchart. For example, two blocks shown in succession can in fact be executed substantially concurrently or the blocks can sometimes be executed in the reverse order, depending upon the functionality / acts involved.

[0095] The description and illustration of one or more aspects provided in this application are not intended to limit or restrict the scope of the disclosure as claimed in any way. The aspects, examples, and details provided in this application are considered sufficient at the time of filing for placing one skilled in the art in possession of the best practices contemplated for carrying out the claimed disclosure. The disclosure as claimed should not be construed as being limited in any way by any of the aspects, examples, or details provided in this application. Skilled persons will be able to devise appropriate measures to modify or replace various features (including structural and methodological features) shown and described in this application, whether in combination or separately, in order to form embodiments having a particular set of features. Through this description and illustration, those skilled in the art will be able to devise variations, modifications, and alternative aspects that fall within the spirit of the general inventive concept embodied in this application, without departing from the broader scope of the disclosure as claimed.

Claims

1. A system for routing a video stream in a one-way transport (OWT) system, the system comprising: a source video proxy (104) in a source computing environment (101), the source video proxy (104) to: receive a video stream on an ingress port at an ingress Internet Protocol (IP) address; based on a corresponding ingress IP address and port of the video stream, access a mapping table storing a unique identifier for the video stream; based on the ingress port and IP address of the video stream, identify a unique identifier for the video stream; generate an enhanced datagram comprising video packets of the video stream and routing metadata comprising the unique identifier, wherein the enhanced datagram forms an enriched video stream; and send the enriched video stream through the OWT system; and a destination video proxy (110) in a destination computing environment secured by the OWT system, the destination video proxy (110) to: receive the enriched video stream; extract the unique identifier from the routing metadata of the enhanced datagram of the enriched video stream; based on the extracted unique identifier, identify a destination address for the video stream from a routing table storing corresponding destination addresses for a plurality of unique identifiers; and send the video stream to a destination device having the destination address.

2. The system of claim 1, wherein the video stream sent from the destination video proxy does not include the routing metadata added by the source video proxy.

3. The system of claim 1, wherein the source computing environment is a low trust environment and the destination computing environment is a high trust computing environment.

4. The system of claim 2, wherein the enhanced datagram comprises up to seven transport stream (TS) packets and a routing packet comprising the routing metadata.

5. The system of claim 4, wherein the routing packet further comprises a reference number and control data indicating whether the enhanced datagram is a start of the video stream, a middle of the video stream, or an end of the video stream.

6. The system of claim 4, wherein the routing packet is a modified null packet.

7. A method for routing a video stream in a one-way transport (OWT) system, the method comprising: receiving (402) by a source video proxy in a source computing environment a video stream having a source address; based on the source address of the video stream, identifying (404) by the source video proxy a unique identifier for the video stream; generating (406) by the source video proxy an enhanced datagram comprising video packets of the video stream and routing metadata comprising the unique identifier, wherein the enhanced datagram forms an enriched video stream; sending (408) by the source video proxy the enriched video stream through the OWT system; receiving (410) by a destination video proxy in a destination computing environment the enriched video stream; ​ ​ ​ extracting (412), by the destination video proxy, the unique identifier from the routing metadata of the augmented datagram of the enriched video stream; identifying (414), by the destination video proxy, a destination address for the video stream based on the extracted unique identifier; and sending (416), by the destination video proxy, the video stream to a destination device having the destination address.

8. The method of claim 7, wherein identifying, by the source video proxy, the unique identifier comprises: accessing a mapping table storing unique identifiers for video streams based on corresponding ingress IP addresses and ingress ports of the video streams; and identifying the unique identifier for the video stream based on the ingress address and ingress port for the video stream.

9. The method of claim 7, wherein identifying, by the destination video proxy, the destination address comprises: accessing a routing table storing corresponding destination addresses for a plurality of unique identifiers; querying the routing table with the unique identifier; and receiving the destination address in response to the query.

10. The method of claim 7, wherein the video stream sent from the destination video proxy does not include the routing metadata added by the source video proxy.

11. The method of claim 7, wherein the destination video proxy receives the enriched video stream from a protection device protecting the destination computing environment.

12. The method of claim 7, wherein the routing metadata is in a modified null packet.

13. The method of claim 12, wherein the augmented datagram includes seven TS packets and a routing packet including the routing metadata.

14. The method of claim 13, wherein the routing packet further includes a reference number and control data indicating whether the augmented datagram is a start of the video stream, a middle of the video stream, or an end of the video stream.

15. A method for routing a video stream in a one-way transfer (OWT) system, the method comprising: receiving (410), by a destination video proxy in a destination computing environment, an enriched video stream, the enriched video stream including an augmented datagram including video packets of a video stream and routing metadata including a unique identifier; extracting (412), by the destination video proxy, the unique identifier from the routing metadata of the augmented datagram of the enriched video stream; identifying (414), by the destination video proxy, a destination address for the video stream based on the extracted unique identifier; and sending (416), by the destination video proxy, the video stream to a destination device having the destination address.

Images