 Hello? Keston. Okay. Perfect. All right. I will be talking about RIST, a new interoperable error correction protocol for the transmission of media streams. So the presentation will be divided in three parts. We will start with a general overview and history of error correction protocols. Then we'll move to talk about the new open source library, LibRIST. And finally, we will talk about some virtual image tools that are available for integration testing. All right. So let's start with the basic concepts first, the error correction protocols. What are the basics? We send media streams using UDPs because we want to maximize bandwidth usage and we want to achieve consistent and reliable latency on a network transmission. However, because UDP has no acknowledgement mechanism like TCP does, and because of this without error corrections, there will be some packet loss. And the packet loss will cause video on audio artifacts in your transmission. There are several possible ways in which we can overcome this, right? We can add redundant data in the packet themselves to rebuild the drop packets. This is called for error correction. Or we can add two-way communications, hold on, adjust this, or we can add two-way communications such that the receiving side will recent for the lost packets and they will be transmitted in real time. This process is called an ARQ, automatic repeat request mechanisms. So the ARQ has been around, the ARQ and the FSM both, they have been around for more than 40 years in one way or another. And there are dozens of open and closed source implementations of both types of protocol. RIST is a new, officially published, interoperable standard to perform this error correction. What are the typical usage of error correction protocols? They're generally used for content streams from remote to the studio for mixing prior to broadcast, cable cast or streaming, for sports, news and opinion shows, foreign TV feeds, ethnic cable offering, mass shootings, etc. In today's world, internet connections have better uptimes than expected least lines. We're going to publish a study of two years of a very large provider that had a number of least lines all over the world and they had in parallel internet lines from the same places. The uptime was higher on the internet lines. However, unlike least lines, internet connections are expected to be lossy. There's an expectation that if you transmit any type of protocol that doesn't have acknowledgement, like UDP, there will be packet loss. So how does it work? The protocol itself. Typically, ignore the image on the right, there's just one particular implementation, but typically they all have the same type of mechanism. You use a time stamp and a sequence number, a sequential number on the sender side and you tag each packet and with this data, the receiver can easily identify any missing packet by looking at the sequence numbers. Upon detection of a lost packet, the receiver is going to request a retransmit to the sender for that missing data and this is all done in real time. Finally, upon the receiving of that missing data, the receiver inserts the packet into the buffer and then this all happens before that part of the contents is delivered to the receiving player or whatever that's on the other side. So what are other additional requirements or a wish list that we would like to have on an error correction protocol? Well, typically implementation of the protocols have to account for the fact that one or both sides of the transmissions might be behind a net with no public IP address, right? Or perhaps a bandwidth is not enough on one ISP for the quality they desire and they need to combine two or more ISP links. Some of these can all be achieved using tricks and techniques like port mapping, VPNs, and bonding. But that would mean that in order to use an error correction protocol, you would need to be also a networking expert to set it all up, right? So instead, these features are in most cases added to the different implementations of error correction protocols out there. So error correction protocols, right? Here's a shameless pitch. DOSER is my proprietary patented protocol and it's typically sold with a hardware or a VM containing a custom version of the Linux OS. DOSER has won several awards including an engineering Emmy for its technology. There are several other proprietary and patented protocols in use today. Most of them leverage their technology to sell reliable links as a service, not just to, you know, they don't just give you the devices. One particular vendor's implementation, High Vision, was published as an open source a couple of years ago under the name of SRT. I've been told that the source code release seems to have some inherent design issues with threat safety and with readability. And up until recently, it had no published specs. I think they finally published an official spec for it. But it is, you know, that particular vendor's implementation of an error correction protocol. So let's dive now into RISC itself. What is it and how it was born, right? Here's an excerpt from the executive summary of the first published RISC, simple profile document. I typically don't like read anything verbatim that's on the screen, but in this case, I think it's worth it. So it basically says, many solutions exist in the market for reliable streaming over the internet. These solutions all use the same types of techniques, but they are all proprietary and do not interoperate. This technical recommendation contains a protocol specification for reliable streaming over the internet so any users can mix and match solutions from different vendors. That pretty much summarizes, you know, why it was born. What was achieved with RISC was very unusual. A group of industry experts, including most, if not all, patent owners of different error correction protocols, they worked together to publish an interoperable standard that was free and clear of all patents, which also included the combined knowledge and experience of all these different vendors that have been using these technologies for the last few years. So this was not a theoretical exercise on the contrary. It was a culmination of a multi-year multi-vendor real-world experiment. So where does it stand now? It has been almost two years since the workgroup started, and we have published two documents. We have published one document and are about to publish the second one. They correspond to the simple profile, which is a TR-061, and the main profile TR-062. Here I also show some of the companies that are part of the group and that are very active. Actually, I forgot to include your company, sorry. You're in the forum. So we have collectively performed several interrupt testing events of each other's implementations. So it's not just one library that everybody uses, but everybody has written their own code and we've done interrupts among everybody. And most notably, RIST is now part of AWS as well as an INGIS mechanism. An important aspect of the design philosophy of the group is that we leverage existing IRFCs as much as practically possible to keep the final spec short and at the same time very well documented. So let's talk about the first, the RIST simple profile that has been already published for over a year and has been implemented by a number of projects. So the simple profile was designed with the idea of graceful degradation. In other words, senders that do not support RIST can still send their streams to receivers that do and vice versa. The one and only requirement is that you transmit your stream with a valid RTP header, which is pretty standard. In addition, when you want packet recovery, you open a second connection from the sender to the receiver and you exchange RTCP packets over that second connection. These RTCP packets can contain, like you see here, an example, timestamps, counter packets sent, et cetera. They can also be empty packets for, you know, like a keep alive to establish state over firewall, et cetera. Now, once this secondary RTCP channel is established, the receiver uses it for retransmission requests, among other things. We'll go more in detail later. So let's recap. Simple profile has its basic characteristics. The use of RTP, you can see that the use of RTP and RTCP were a result of the design goals for the simple profile which was graceful degradation and leveraging of existing standards and specs. So pretty simple. It's somebody that has an RTP implementation. It will take them a day to add a packet recovery to it. Possible RTCP messages used, you know, these are standard messages and we leverage them for the protocol. On the sender side, we have sender reports, empty reports, source description, receiver, we have a receiver report, and the most important, the negative and acknowledgement packet to request the missing packets. All right. Here is how this NAC-based recovery works with a little bit more detail. An important thing to consider in this diagram is that, as you can see, we have the first packet loss not received and the receiver side does not send the acknowledgement immediately. There's a gap there. And that gap is important because we need to account for packet reordering. In UDP transmissions, there's always a possibility of packet reordering, not only packet loss. So the receiver might interpret a missing sequence as a loss when in reality it's just a reorder packet that arrives later. So it's important for us to have this gap before we request the first transmission. So the NAC messages send back to the sender, the sender processes and sends the packet again, the data packet, and then continues with the natural flow in parallel. And that's pretty much the mechanism. It's very simplistic, very effective. It's something that has been around for 40 years. And it requires certain parameters which are all specified in detail. We support two types of NAC messages. We use either a bitmask or a range and it's up to the receiver to request one or the other. One might be more efficient on the other depending on the amount of data loss the network is exhibiting. So we also suggest some defaults based on experience by, you know, it was a consensus among all the vendors and everybody that participated that for a typical internet connection from one coast to the US to the other or across the Atlantic or anywhere across Europe, these defaults work quite well. If you can sustain a thousand milliseconds of latency which is the size of the buffer on the sender side, these parameters will work quite well for any internet link. Well, in reality, if you see the graph on the right, a protocol can be implemented also to make those parameters dependent on the roundtrip times. It's not necessarily fixed. A good implementation will use a real-time measurement of the roundtrip time to adjust the parameters in real-time. So let's move now to the main profile which is the one that's about to be published. It's supposed to be published by, you know, today but it's still under review. It's going to come out in the next couple of weeks. So for the main profile, which came basically a year after the simple profile, the design goals were slightly different. We now needed to achieve multiplexing and encryption and some other requirements as well which we'll go over. For this, then we didn't need or require any type of graceful degradation. Main profile connections can only, you know, be established among two RIST devices. There's no longer the universality of having an RTP stream be the first thing that each other sees. So what does the main profile bring to the table? We needed a way to multiplex, so we used GRE, GRE tunneling. Why GRE? Well, one, it eliminates the use of an extra port. It allows for the multiplexing of streams. There are published encryption and authentication standards we can use on top of it. In our case, we chose ETLS and a former pre-shared key. GRE stands for general encapsulation. We can also separate another important side effect or having now one port and one multiplexing is that we can separate the connection initiation role from the packet recovery role. So this allows for the possibility that either side can be behind a NAT or firewall. It's no longer like in the simple profile case where the receiver side had to have either a public IP or a port mapping. Now either side can sit behind a NAT and we can establish the connection at the GRE level, at the tunnel level, and then on top of that, we can send the data with the packet recovery. An additional benefit or GRE that if they implement the desired set, it allows for the tunneling of any other type of data ground, not only UDP or streams, video streams. All right, so after the GRE protocol header, and we support two types of headers, if you look at it here, the typical use, you have a UDP header where you transmit your data and you have now the GRE header right here with the optional flags. One of the parameters of the GRE header is what protocol type is going to be your payload. So you can do a standard IP payload, which is a full datagram mode, and then this now becomes just an IP datagram. You're going to have another IPv4 header or an IPv6, whatever you prefer, and then you payload under it. But we also added support for a new protocol type that's not part of the normal GRE specification, specific for RIST, to use it for reduced overhead. The new type only uses 4 byte source port and destination port. And then it assumes that what follows is an RTP message just like with a simple profile. So you can do it as simple or as complicated as you want. So there are two possible encryption methods supported by the main profile. DTLS and PSK. DTLS uses SSL certificates and all the security complications that are associated with certificates. PSK, on the other hand, supports a simpler passphrase mode with the downside that now you have to get that passphrase communicated to both ends through some secure channel, a phone call, preferably a secure way. But now you have to perform that outside of the scope of the protocol. So what is the current status of RIST of this protocol? We have the simple profile. It was completed, integrated and tested. It's part of VLC, U-pipe, G-streamer, and others. It's on all the vendors that are part of the workgroup and people keep adding the simple profile on a weekly basis. The main profile that adds the GRE encapsulation and the encryption, it was finished and sent to review just a few weeks ago. We were expecting to be done by now. It's most likely going to be done before the month is over, probably within the next week or two. There's a new open source library that was created with the main profile called LibRIST. The main library is going to live under the umbrella of the VLC, JITLAB, code-based with a public group. It was coded and following the standards of the David decoder. Same rules that's applied for both. And we're waiting for the document to be officially published so that we can push the library to the repo. Right now, the repo is simply waiting for that document to be published. The main profile is scheduled to have interrupt between all the companies at California in the next two weeks at Cobalt's offices. And then after that, there's an immediate BSF conference where there's also going to be a demo of all the companies interoperating at about nine of them, I believe, showing the main profile with the RISP being transmitted from different parts of the world to a local monitor there. All right, so let's talk about LibRIST now. Basic features. It's a library, simple APIs, multi-thread safe. It has sample applications with it. The sample applications are just for a single stream, but the library supports any number of it. The library supports point-to-point, point-to-multipoint. You can configure every aspect of it. And best of all, it hides all the complexities of notting, port mapping, keep alive, sockets. You don't need to be a networking expert to use it or to implement it. With 20 lines of code on each side, you have a risk connection between two endpoints. Your code doesn't even need to open the sockets. So what are the more advanced features of the library? AS encryption, either DTLS or PSK. Right now the current LibRIST only supports PSK. Somebody wants to help out with DTLS. They're welcome. Multiple streams. We have an optional compression that is not part of the standard, but we found that it's effective in some streams. We can encapsulate multicast. And now we can specify which side is going to initiate the connection, independent of which side is sending the stream. All that is supported in the library. For somebody that wants to implement advanced features, they're not part of the sample application that comes with it. It's very simplistic. So next, the virtual images. Right? How can we make it easier for people to implement the protocol, the standard, right? Well, step one is to provide false library, which we have already done. We have a list ready to be published. Step two is to provide an easy way to use a pre-wrap OS image that has the application and library already compiled inside and give them a simple GUI to configure it as a relay. So they don't even have to compile the library. They compile the code. They just grab the image, put it on the virtualization engine of their choice, and test their code against that image. That image will serve as a relay, receive it, let them play it in VLC, reverse ascending and let you play a content that you put on the image. Shameless speech again. The idea is that you will love the image so much that you will want to buy other flavors of images that have more functionality. So demo applications. Here's the workflow of a typical use of the image or the sample applications that's included with the library itself. On the re-sender side, we listen to a UDP port, read a local stream, UDP standard, encapsulating it to RISC and send it to multiple locations encrypted. Similar to what they've shown in several presentations today, that was done. On the receiver side, we read the re-stream, decrypted, and output to the next-stage device. It could be a player, or maybe you want to output as a local network multicast to be used locally in the receiver side for other purposes. So possible uses of the image, tested, learned, ad-hub, live stream, transmittal, a relay, development, whatever you want to use it for. Some more advanced use cases that are not available in the current sample application are, you know, virtual tap or tone interfaces. You can actually bridge two machines using top-tap interfaces using the RISC protocol and have zero configuration mode for the streams. Whatever you push on one side, automatically ships up in the other machine across the internet with the error correction on it. So this allows for the easy multiplexing of streams. We also support in the library already load balancing and redundancy and there are no limitations of any kinds for the use of the library in commercial applications. The license model is the same as the David. I forget if it's LG. I think it's not a GPL. It's an even looser one. So, thank you so much. There are a few questions. Does the library still offer a socket-based API like LibreSRT so people can drop things in? I'm not sure I understand the question. What do you mean by... Oh, I see. We don't have that now, but it would be a very easy to add. An emulator, yes. The code will be online and it's very clear or structured, so it will be easy to follow. I tried once to read the SRT code. Successfully. Firewall portal opening can be a problem in some organization. Do you have a mode? Is Firewall traversal like stun? I think so. What we have, we have the ability to initiate the connection from either side. So, if one organization is giving you problems, just go to the other end and get a public IP or a port mapping there and you'll be able to establish connection. A lot of the time, it's easy to get an outbound port open or it's already open and you don't have to do anything. Finally, are all these competing protocols a problem? It does stuff to after all and it's implemented in products. Well, it's a problem because until one standard dominates, you know, somebody that wants to create a new link is going to have to decide. Do I use RISC? Do I use SRT? Do I buy Dozer? Do I buy some other implementation? What do I do? So, I paid my money on RISC. But I'm biased, so... Another question from the floor. Do you recognize the room? The EBU from St. Ben who helped us film everything, the camera, and all of you attended and will now help us clean the room. So, please take all the trash that you can and put it in the trash can. Thank you.