|
|
**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
|
|
|
![6-1](uploads/cd7e6cd6d8da6a41c3859544b8f5f5dd/6-1.png)
|
|
|
|
|
|
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.
|
... | ... | @@ -119,8 +120,8 @@ RIST Main One Sender to Two Receivers External Addresses |
|
|
|
|
|
![6-6](uploads/33a8df52cf68d249ff313db1d474f908/6-6.png)
|
|
|
|
|
|
* Receiver \#1 listens on external adapter port 14212 (arbitrary).
|
|
|
* Receiver #2 listens on external adapter port 14121 (arbitrary).
|
|
|
* 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.
|
... | ... | |