WARP tracking issue

Summary

WARP is an acronym (coined by @juberti) that stands for "WebRTC Abridged Roundtrip Protocol" which cuts down the amount of round-trip involved in establishing a WebRTC connection from 6 to 2.

IETF drafts:

• SNAP https://datatracker.ietf.org/doc/draft-hancke-tsvwg-snap/
• SPED https://datatracker.ietf.org/doc/draft-hancke-webrtc-sped/ (read with a grain of salt, lots of details do not match the implementation)

The pion implementation spans multiple repos and PRs which are tracked here. One part is SNAP which skips two round trips in opening the datachannel:

• SCTP SNAP implementation https://github.com/pion/sctp/pull/449
• +WebRTC SNAP implementation https://github.com/pion/webrtc/pull/3327+

The second (and more complicated) part is SPED, embedding the DTLS handshake in the STUN/ICE connection establishment. This is going to span multiple PRs in several repos:

• STUN changes https://github.com/pion/stun/pull/260
• ICE changes to read and write the attributes https://github.com/pion/ice/pull/861
• ICE changes to insert and process the attributes with the correct semantics https://github.com/pion/ice/pull/876
• ICE changes to make the API nonblocking so that DTLS can start at the same time as DTLS https://github.com/pion/ice/pull/862
• DTLS changes to intercept/get notified about inbound and outbound DTLS packets and inject them from non-network sources https://github.com/pion/dtls/pull/766
• WebRTC changes to glue everything together, mainly in the ICE and DTLS transport and how they are started (https://github.com/pion/webrtc/pull/3362
• WebRTC changes that allow handling non-actpass offers so that the client (i.e. a browser) can send the DTLS client hello with the first outgoing STUN packets https://github.com/pion/webrtc/pull/3325

Last but not least

• A demo for testing all this https://github.com/pion/webrtc/pull/3326

with me, this is going to be a bit of a mess