|
|
|
**Overview of the Mechanism**
|
|
|
|
|
|
|
|
The RIST processes provide an automatic re-request mechanism for dropped or corrupted packets, and places any mis-ordered packets back in the right order. The illustration below shows the header from a message packet from receiver to sender, requesting a resend for a range of packets that the receiver detected were missing.
|
|
|
|
ys (per the key rotation), and other "housekeeping" for the two tunnels. Thereafter all but those fields in the packet header specified by the protocol spec will be encrypted by the sender, decrypted by the receivers.
|
|
|
|
Sender ingests the stream from 192.168.1.124, encryp
|
|
|
|
|
|
|
|
|
|
|
|
In general you start the RIST sender(s) and receiver(s) first, and the media stream and client viewer after. This is not a technical necessity, and in the case of live streams, is not always feasible. It simply makes sure the receiver side receives the first frames of the media.
|
|
|
|
|
|
|
|
In the simple protocol, the sender must initiate, by which we mean the client listens on its port, and the sender establishes the connection by contacting the receiver. With the main protocol, either side, sender or receiver, can initiate the RIST connection. You must, however, specify which side is to be the initiator before establishing the connection. The other side waits and listens.
|
|
|
|
|
|
|
|
In a case in which one side has a publicly accessible IP address, and the other side is NATted, the side with the public address had best be the listener. It is necessary for the "listening" side to open its firewall (udp) on the RIST port. In the case of Simple protocol, in which media requires one port, and messaging another, an additional (udp) port must be opened in the firewall.
|
|
|
|
|
|
|
|
The RIST sender listens for the media on one IP/Port, presumably from a host in the local network. As it receives and forwards each media packet (to the receiver, presumably not in the local network), it also creates and sends to the receiver a "message" that includes the number of packets sent so far, and a time stamp.
|
|
|
|
|
|
|
|
As an example, if a host in the local network, at IP 192.168.1.11 is the media source, and it emits an rtp MPEG/TS stream directed at the local network adapter of the RIST sender, for example, 192.168.1.12:8193, the sender will listen, receive it, then emit the media out of its external adapter, for exampe, 123.123.123.123, sending it to a receiver via the Internet at address, for example, 134.134.134.234:1904.
|
|
|
|
|
|
|
|
If using the Simple protocol, a second port will be necessary for the messaging (from sender, the messages containing the timestamp and total packets sent so far; from the receiver, reports containing the last packet count received, or requests to resend a packet when a missing packet is detected). With the Main or Advanced protocols, a tunnel is usually set up on the one port, and both media and messaging packets are sent through the single port used by the tunnel.
|
|
|
|
|
|
|
|
On the receiver side, the process basically consists of examining the incoming media packets and reading the messages. rtp streams contain a sequence number, which makes it easy to look for omitted packets, and to make sure they're in the right order. The receiver re-requests any missing, which it does by their sequence number.
|
|
|
|
|
|
|
|
For the Main protocol, additional information may be placed inside the rtcp messages. These may include rotating encryption key informatrion, based upon a pre-shared key. An illustration of the encryption information as it resides in the packet header is shown below..
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
On the receiving side, after a short delay which allows time for re-request messages to travel to the sender, and the re-requested media packet to travel back, the stream is fully assembled, in the correct order, and, based upon the time stamp information, forwarded to a player or other application as a "reproduction" of the original media stream, each packet being emitted with the precise relative timing as it was received at the incoming media port on the sender.
|
|
|
|
|
|
|
|
* The sender is called the RIST client. The receiver is called the RIST server. This can be confusing to some, so we try to use "sender" and "receiver" as much as possible.
|
|
|
|
* You will find, with experience using RIST, that if you take the time to properly "tune" your settings, by which we mean observing a connection during the first twenty four hours and setting the optimum maximum bitrate and buffer size, which are the two settings that most affect the ability of the RIST connection to weather the "ups and downs" of the public Internet, your connections will be extremely dependable, with uptimes measured in weeks and months.
|
|
|
|
* Some commercial error correction protocols take a "sledge hammer" approach by which they use far more bandwidth and/or processing power than necessary. Global broadcasting networks with very large budgets generally use such protocols. You will find that though it is possible to be overgenerous with such settings, it is usually not necessary with libRIST.
|
|
|
|
|
|
|
|
You shall see that RIST offers a very rich variety of options. We recommend that you start out simple and work your way up through the more complicated options.
|
|
|
|
|
|
|
|
**Further Notes on Profile Type**
|
|
|
|
|
|
|
|
This is to provide a few guidelines to help you choose the right profile for your stream.
|
|
|
|
|
|
|
|
* If you are just working with RIST for the first time, start with the Simple profile for your first efforts. There is less to configure.
|
|
|
|
* If interoperablity with another vendor's implementation of RIST is required, also start with the Simple profile. Move up to the Main profile after you've successfully tested the Simple.
|
|
|
|
* If your first tests don't work, check the firewall. Everyone forgets the firewall at some time or another.
|
|
|
|
* Remember that Simple profile requires a second port, which will be the next higher in number. The firewall needs to be open for both.
|
|
|
|
* The primary advantage of Main vs. Simple profile is the use of a single port, and the ability to provide encryption.
|
|
|
|
* If using encryption, if your client is unable to play the stream, and the statistics show that the stream is traversing the RIST connection, check to make sure both sides are using the same passphrase.The illustration below shows a timeline in which a sender is joined by multiple receivers, all knowing the passphrase, each computing the current key from the original passphrase at separate times:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Also if using encryption: a number of experts feel that the additional security of AES-256 and AES-192 vs. AES-128 may not be "worth the bang for the buck." You can easily find articles on this topic with a web search. When encrypting or decrypting in a commercial mega-vendor's cloud, CPU usage costs can mount. It is always up to you to set the proper "value" upon the security of your stream. We recommend you do the research and make the decision you feel is best.
|
|
|
|
|
|
|
|
**Further Notes on Routing**
|
|
|
|
|
|
|
|
There are a number of scenarios regarding additional senders and receivers, and network routing.
|
|
|
|
|
|
|
|
* A sender can send one or multiple streams to multiple receivers.
|
|
|
|
* The receiver doesn't necessarily have to know about all of those multiple streams.
|
|
|
|
* Inside the tunnel, we can use multicast addresses for the stream address. But that doesn't mean you can see tem as separate from inside your OS. As far as your OS is concerned, it's just a lot of udp protocal traffic from one particular address/port to another particular address/port.
|
|
|
|
* When sending multiple streams, each stream receives an arbitrary ID number, so that it can be properly identified at the receiving end.
|
|
|
|
When having problems trying to play such a multi-plexed stream, the first thing to check is that you are trying to play the right ID number.
|
|
|
|
* Where you have a sender/receiver combination with multiple Internet provider paths between them, you may use both paths. You may split the stream along both paths for speed, or duplicate it for redundancy.
|
|
|
|
|
|
|
|
**Configuring and Tuning**
|
|
|
|
|
|
|
|
By tuning a connection, we mean the process of choosing the right bandwidth options, buffer size, and re-request timing parameters for your stream(s). Because a given Internet routing can be different than another, you will find that "tuning" your connection will be very important for the quality and long term health of your stream(s). It is our experience that by investing a day of monitoring and adjusting up front, a proper error correcting protocol connection can return excellent results for periods of months or even years. We have seen ECP streams running under the worst imaginable network conditions, yet we have seen have run for months and months without changing the configuration at all, because we went through the trouble of configuring them well at the start.
|
|
|
|
|
|
|
|
You'll always wish to configure your max bandwidth to be higher than the max bandwidth of your stream(s). That's obvious: you have to allow room for messages that re-request and the re-requested packets. You should start at 10% higher for a constant bitrate, 100% higher for variable bitrate. You'll find that RIST works great with constant or average bitrate streams. As for your variable bitrate streams, if they are very variable, you may run into trouble unless you provide a great deal of "headroom" in your bandwidth, and sometimes, your buffer settings!
|
|
|
|
|
|
|
|
The buffer size will work best at four to seven times the ping time. This allows time for requests for the retransmission of a lost or corrupted packet, and the subsequent retransmission of its replacement. If your stream traverses undersea fiber routes or other types of sometimes unstable or congested routes, you may require an even bigger buffer. This buffer will "delay" the stream by the amount of the buffer (in milliseconds), but the stream will arrive without added jitter.
|
|
|
|
|
|
|
|
The minimum and maximum rtt settings also control the minimum and maximum times to wait before re-requesting when a re-request hasn't yet been fulfilled. This is important in situations where network congestion may come into play. You can raise the minimums on a connection in which you always experience good quality.
|
|
|
|
|
|
|
|
**Other General Notes**
|
|
|
|
|
|
|
|
|
|
|
|
The server hardware can run as many RIST servers (and clients) as the hardware (and licensing) supports. In general, the CPU processing for RIST is very reasonable, a small fraction that of transcoding a stream, for example.
|
|
|
|
|
|
|
|
Both sender and receiver settings will be found under the libRIST tab within the Coral user interface. The sender/sender configurations start with "XMIT," and the receiver configurations start with "RECV." The "tab" listings will show the receivers first. This document will notate the sender first, because we recommend you always configure the tranmitter first for every RIST peer connector you set up.
|
|
|
|
|
|
|
|
Once you've configured the RIST part, the input and output stream configurations on the Stream Setup tab(s) will have access to your sender (or receiver) as if they were any other output or network location. If you are using a free or evaluation VM image of libRIST, you should see one tab in the Stream Setup menu. Others are limited only by license. In the various source and destination dropdowns there, you will find listings for your RIST configurations. These listings will include the "friendly names" you set for your libRIST configurations. This is why we always recommentd you set up the friendly names to be descriptive and easily recognizable. This also makes it easier to find the right configuration should you need to change something, particularly if long periods pass between changes to the configuration.
|
|
|
|
|
|
|
|
For Simple protocol configurations, you simply point your outbound UDP (or RTP, though UDP is generally simpler and easier) stream configuration at the port you had set up for RIST (most likely at the localhost, 127.0.0.1 adapter). The simple protocol is currently supported in vlc 4.0 (beta at this time, though there is a plug in available for vlc 3.x), and it is expected that many client viewing applications will support RIST in a short while. Though it may not support encryption and multi-plexing, the RIST simple protocol is expected to become very popular.
|
|
|
|
|
|
|
|
You'll find also that we include a "Notes" area for each RIST configuration. Our customers are accustomed to setting up configurations and leaving them operational and in place for long periods of time. It is easy to forget what you set up, why you set a certain parameter a certain way, or sometimes, you may need to figure out something a predecessor left for you. That's why there's a notes field.
|
|
|
|
|
|
|
|
**Network Diagrams/Routing Scenarios**
|
|
|
|
|
|
|
|
We've diagrammed a few scenarios below, so that you can visuallize the "combinations" of send/receive more easily.
|
|
|
|
|
|
|
|
RIST Simple One to One External Addresses
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Receiver listens on external adapter ports 8194 and 8195 (1st port arbitrary, but must be an even number).
|
|
|
|
* Sender connects with receiver, exchanges rtcp messages on 8195.
|
|
|
|
* Sender forwards the ingested stream from its external address to port 8194 on the receiver.
|
|
|
|
* Messages flow back and forth on 8195.
|
|
|
|
Receiver places media packets in its buffer, examines sequences, timestamps.
|
|
|
|
* In case of lost packet, receiver sends re-request to sender over 8195.
|
|
|
|
* Sender re-sends lost packet to receiver over 8194.
|
|
|
|
* Receiver outputs stream with all packets to 192.168.2.235
|
|
|
|
|
|
|
|
RIST Main One to One Private Address Receiver Initiates
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Sender listens on external adapter port 14211 (arbitrary).
|
|
|
|
* Receiver contacts sender, firewall on the receiver side sees established connection.
|
|
|
|
* Receiver's Gateway NATs the subsequent receiver side traffic.
|
|
|
|
* Receiver handshakes with Sender, they calculate the keys (per the key rotation), and other "housekeeping" for the two tunnels. Thereafter all but those fields in the packet header specified by the protocol spec will be encrypted by the sender, decrypted by the receiver.
|
|
|
|
* Sender ingests the stream from 192.168.1.124, encrypts and outputs through the tunnel.
|
|
|
|
* Messages flow back and forth, also encrypted.
|
|
|
|
* Receiver places decrypted media packets in its buffer, examines sequences, timestamps.
|
|
|
|
* In case of lost packet, receiver sends re-request to sender..
|
|
|
|
* Sender re-sends lost packets to receiver.
|
|
|
|
* Receiver output stream with all packets to 192.168.2.235 as per the diagram
|
|
|
|
|
|
|
|
One Sender, One Receiver, Two Streams, Two Origins, Two Destinations, Sender Inititates
|
|
|
|
|
|
|
|
RIST Main One Sender to Two Receivers External Addresses
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Receiver No.1 listens on external adapter port 14212 (arbitrary).
|
|
|
|
* Receiver No.2 listens on external adapter port 14121 (arbitrary).
|
|
|
|
* Sender handshakes with receivers, they calculate the keys (per the key rotation), and other "housekeeping" for the two tunnels. Thereafter all but those fields in the packet header specified by the protocol spec will be encrypted by the sender, decrypted by the receivers.
|
|
|
|
* Sender ingests the stream from 192.168.1.124, encrypts and outputs through the tunnels.
|
|
|
|
* Messages flow back and forth, also encrypted.
|
|
|
|
* Each receiver places decrypted media packets in its buffer, examines sequences, timestamps.
|
|
|
|
* In case of lost packet, receiver(s) sends re-request to sender..
|
|
|
|
* Sender re-sends lost packets to only the receiver that requested the resend..
|
|
|
|
* Receivers output streams with all packets to 192.168.2.235 and 192.168.3.35, as per the diagram
|
|
|
|
|
