Added and updated handshake description #351

ethouris · 2018-04-18T10:51:14Z

No description provided.

stevomatthews · 2018-05-28T22:31:52Z

I went through the entire document and made significant changes to hopefully improve readability. Note that there are several questions, indicated by ???, that will have to be resolved before final release of this document.
handshake.md.zip

stevomatthews

handshake-28Jun2018.zip

stevomatthews · 2018-07-10T15:36:29Z

docs/handshake.md

+   0                   1                   2                   3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |1|          Message Type         |    Message Extended Type    |


I believe the bar should be directly under the "6", not the "7".

Yes, and the less significant digit bar should be also better aligned.

stevomatthews · 2018-07-10T18:43:52Z

docs/handshake.md

 The **Extension Flags** subfield in the `Type` field in a conclusion handshake
 message contains one of these flags:

 - `HS_EXT_HSREQ`: defines SRT characteristic data; always present
 - `HS_EXT_KMREQ`: if using encryption, defines encryption block
 - `HS_EXT_CONFIG`: informs about having extra configuration data attached

-The extension block has the following structure:
+The above schema shows the HSv5 packet structure that can be split into


The above schema shows the HSv5 packet structure, which can be split into

stevomatthews · 2018-07-10T18:47:41Z

docs/handshake.md

+3. The KMREQ extension
+
+Note that extensions are added only in certain situations (as described
+above with the handshake process), so sometimes there are no extensions


above), so sometimes there are no extensions

stevomatthews · 2018-07-10T18:48:20Z

docs/handshake.md

+Note that extensions are added only in certain situations (as described
+above with the handshake process), so sometimes there are no extensions
+at all. When extensions are added, the HSREQ extension is always present.
+The KMREQ extension is added only if the encryption is requested (the


The KMREQ extension is added only if encryption is requested (the

stevomatthews · 2018-07-10T18:49:34Z

docs/handshake.md

+above with the handshake process), so sometimes there are no extensions
+at all. When extensions are added, the HSREQ extension is always present.
+The KMREQ extension is added only if the encryption is requested (the
+passphrase is set by `SRTO_PASSPHRASE` socket option). There might be


passphrase is set by the SRTO_PASSPHRASE socket option). There might also be

stevomatthews · 2018-07-10T18:50:07Z

docs/handshake.md

+at all. When extensions are added, the HSREQ extension is always present.
+The KMREQ extension is added only if the encryption is requested (the
+passphrase is set by `SRTO_PASSPHRASE` socket option). There might be
+also other extensions following.


other extensions.

What I meant is that the other extensions may appear after HSREQ and KMREQ, not just that they can be present.

stevomatthews · 2018-07-10T18:55:22Z

docs/handshake.md

-when the payload was retransmitted.
+2. **Retransmission** flag (1 bit). Controlled by `SRT_OPT_REXMITFLG`, this flag 
+is 0 when a packet is sent the first time, and 1 when it is retransmitted (i.e. 
+requested in a loss report). When the incoming packet is belated (one with a


requested in a loss report). When the incoming packet is late (has a

stevomatthews · 2018-07-10T18:56:22Z

docs/handshake.md

+is 0 when a packet is sent the first time, and 1 when it is retransmitted (i.e. 
+requested in a loss report). When the incoming packet is belated (one with a
+sequence number older than the newest received so far), this flag allows the
+Receiver to distinguish between a retransmitted packet and reordered packet.


Receiver to distinguish between a retransmitted packet and a reordered packet.

stevomatthews · 2018-07-10T18:56:42Z

docs/handshake.md

+sequence number older than the newest received so far), this flag allows the
+Receiver to distinguish between a retransmitted packet and reordered packet.
+This is used by the "reorder tolerance" feature described in the API
+documentation under "SRTO_LOSSMAXTTL").


documentation under "SRTO_LOSSMAXTTL".

I fixed it also to:

documentation under SRTO_LOSSMAXTTL socket option.

stevomatthews · 2018-07-10T18:58:41Z

docs/handshake.md

 - If both have declared encryption, but have set different passwords,
-the Responder will send a KMRSP block with `SRT_KM_S_BADSECRET` value.
+the Responder will send a `KMRSP` block with an `SRT_KM_S_BADSECRET` value.
+The transmission in both direction will be "scrambled" (encrypted and


The transmission in both directions will be "scrambled" (encrypted and

stevomatthews · 2018-07-10T18:59:53Z

docs/handshake.md

+direction (forward KMX) is updated. HSv4 relies only on these messages, so 
+there's no difference between initial and refreshed KM exchange. In HSv5 the 
+initial KM exchange is done within the handshake in both directions, and then 
+the key refresh process is started by the sender and it updates the key for one


the key refresh process is started by the Sender and it updates the key for one

ethouris · 2018-08-06T19:45:08Z

docs/handshake.md

+which the socket was bound. If the cookies are identical (for any reason), the 
+connection will not be made until new, unique cookies are generated (after a 
+delay of up to one minute). In the case of an application "connecting to itself", 
+the cookies will always be identical, and so the connection will never be made).


Superfluous closed parenthesis.

ethouris · 2018-08-06T19:54:58Z

docs/handshake.md

+between connected parties) over this connection, it may switch to the `Connected`
+state just as if it had received a `URQ_AGREEMENT` message.
+
+4. If the the Initiator is already switched to the `Connected` state it will not 


ethouris · 2018-08-06T20:00:39Z

docs/handshake.md

+
+1. The Handshake data part (up to "Peer IP Address" field)
+2. The HSREQ extension
+3. The KMREQ extension


I think it would be nice to mark somehow this breakdown on the schema.

HSv5_PacketStructure_30Apr2019.md.zip

ethouris · 2018-08-06T20:07:40Z

docs/handshake.md

+Declares the `SRTO_TLPKTDROP` flag of the party. This is important
+because both parties must cooperate in this process. In HSv5, if both
+directions are TSBPD, both use this setting. This flag must always be
+ set in live mode.


It's not true that this flag must be always set in live mode, although this is default and most recommended.

Change last sentence (lines 1181-1182) to:
"While it is not always necessary to set this flag to live mode, it is the default and most recommended setting."

ethouris · 2018-08-20T06:54:27Z

docs/handshake.md

+
+- If the Initiator declares encryption, but the Responder does not, then
+the Responder responds with `SRT_KM_S_NOSECRET` status. This means
+that the Responder will not be 


To avoid confusion here, I'd say it explicitly that it's a string that a Caller can pass to a Listener (it's actually passed from an Initiator to a Responder in general, but in Rendezvous connections this feature doesn't make sense).

ethouris · 2019-05-02T14:13:36Z

I'm kinda confused. The comments show text that is completely irrelevant to the cited document parts. Is this document now considered fixed?

Added and updated handshake description

7e31dc5

rndi requested a review from stevomatthews April 18, 2018 15:41

Added description of rendezvous handshake with different versions

1bc7cb8

rndi and others added 5 commits May 28, 2018 18:45

Applied edits from @stevomatthews

c24cd4c

Some redactions

7acdacc

Added more changes after review

a1d1fc7

Updates and fixes for handshake description

14c6a95

Applied one forgotten fix

9e3071e

stevomatthews reviewed Jun 28, 2018

View reviewed changes

Added changes from collaborative works

fd3aec8

stevomatthews reviewed Jul 10, 2018

View reviewed changes

Fixes after Steve's review

97386cc

ethouris commented Aug 6, 2018

View reviewed changes

ethouris commented Aug 20, 2018

View reviewed changes

ethouris added Status: In Progress labels Jan 18, 2019

ethouris added this to the v.1.3.3 milestone Jan 18, 2019

ethouris added the Priority: High label Jan 21, 2019

Added changes for diagram

f1256ae

stevomatthews approved these changes May 2, 2019

View reviewed changes

maxsharabayko added the [docs] Area: Improvements or additions to documentation label May 2, 2019

Mikołaj Małecki added 2 commits May 2, 2019 16:47

Added some extra fixes

8fd6b60

Added some extra fixes 2

9032640

rndi merged commit 3d159f0 into Haivision:master May 2, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Added and updated handshake description #351

Added and updated handshake description #351

ethouris commented Apr 18, 2018

stevomatthews commented May 28, 2018 •

edited

Loading

stevomatthews left a comment

stevomatthews Jul 10, 2018

ethouris Jul 11, 2018

stevomatthews Jul 10, 2018

stevomatthews Jul 10, 2018

stevomatthews Jul 10, 2018

stevomatthews Jul 10, 2018

stevomatthews Jul 10, 2018

ethouris Jul 11, 2018

stevomatthews Jul 10, 2018

stevomatthews Jul 10, 2018

stevomatthews Jul 10, 2018

ethouris Jul 11, 2018

stevomatthews Jul 10, 2018

stevomatthews Jul 10, 2018

ethouris Aug 6, 2018

ethouris Aug 6, 2018

ethouris Aug 6, 2018

stevomatthews Apr 30, 2019

ethouris Aug 6, 2018

stevomatthews Apr 30, 2019

ethouris Aug 20, 2018

ethouris commented May 2, 2019

Added and updated handshake description #351

Added and updated handshake description #351

Conversation

ethouris commented Apr 18, 2018

stevomatthews commented May 28, 2018 • edited Loading

stevomatthews left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ethouris commented May 2, 2019

stevomatthews commented May 28, 2018 •

edited

Loading