Source code
Revision control
Copy as Markdown
Other Tools
Piggybacking DTLS on Stun is a mechanism whereby we send the initial DTLS
handshake over the STUN exchange that opens up the data path, thereby saving round
trips.
The implementation is in dtls_stun_piggyback_controller.{h,cc} and is tested by
dtls_ice_integration_test.cc.
The state machine is as follows:
Initial state:
CLIENT: TENTATIVE
SERVER: TENTATIVE
A "flight" is a set of one or more DTLS messages (see resp. RFC).
*** DTLS1.2 (RFC 6347) ***
Flight 1: CLIENT => SERVER
SERVER when receiving Flight 1: TENTATIVE => CONFIRMED
Flight 2: SERVER => CLIENT
CLIENT when receiving Flight 2: TENTATIVE => CONFIRMED
Flight 3: CLIENT => SERVER
SERVER when receiving Flight 3: CONFIRMED => PENDING (dtls writable)
Flight 4: SERVER => CLIENT
Client when receiving Flight 4: CONFIRMED => COMPLETE (dtls writable)
SERVER will switch to COMPLETE when one of
- Flight 4 is acked
- It receives decryptable data from CLIENT (i.e. it learns that CLIENT is dtls writable)
*** DTLS1.3 (RFC 9147) ***
Flight 1: CLIENT => SERVER
SERVER when receiving Flight 1: TENTATIVE => CONFIRMED
Flight 2: SERVER => CLIENT
CLIENT when receiving Flight 2: TENTATIVE => PENDING (dtls writable)
Flight 3: CLIENT => SERVER
SERVER when receiving Flight 3: CONFIRMED => COMPLETE (dtls writable)
CLIENT will switch to COMPLETE when one of
- Flight 3 is acked
- It receives decryptable data from SERVER (i.e. it learns that SERVER is dtls writable)