| ... | ... | @@ -3,7 +3,7 @@ |
|
|
|
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.
|
|
|
|
|
| ... | ... | @@ -21,7 +21,7 @@ On the receiver side, the process basically consists of examining the incoming m |
|
|
|
|
|
|
|
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.
|
|
|
|
|
| ... | ... | @@ -42,7 +42,7 @@ This is to provide a few guidelines to help you choose the right profile for you |
|
|
|
* 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.
|
|
|
|
|
| ... | ... | @@ -86,7 +86,7 @@ We've diagrammed a few scenarios below, so that you can visuallize the "combinat |
|
|
|
|
|
|
|
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).
|
| ... | ... | @@ -100,7 +100,7 @@ Receiver places media packets in its buffer, examines sequences, timestamps. |
|
|
|
|
|
|
|
RIST Main One to One Private Address Receiver Initiates
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Sender listens on external adapter port 14211 (arbitrary).
|
| ... | ... | @@ -118,7 +118,7 @@ One Sender, One Receiver, Two Streams, Two Origins, Two Destinations, Sender Ini |
|
|
|
|
|
|
|
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).
|
| ... | ... | |
