とりあえず、Google の記事を読んでください。
WebRTC over QUIC は WebRTC DataChannel を QUIC で置き換えた実装になっています。さらに RTCPeerConnection や SDP といったものが消え去った API になっています。
RTCQuicTransport を使って QUIC の接続を確立します。ただ P2P なので ICE が必要なので RTCIceTransport が必要になります。
そのため Candidate を取得して、シグナリング経由でお互い投げつける。SDP が出てこないだけでこの辺は WebRTC と一緒ですね。
ただ、ちょっと違うのが QUIC 側が PSK を交換する前提になっています。これはおそらくですが 0-RTT を利用するためでしょう。なので Listen 側に PSK をシグナリングで渡しています。つまり「再接続状態」をシグナリングを利用して実現し、0-RTT をいきなり利用可能にしています。
ちなみに IceParameters は普通に STUN パケットによる、UDP ホールパンチング用です。中身は username/password です。
QUIC が start して connect/listen で接続が確立したらあとは、createStream を呼び出す必要があります。
QUIC ではストリームを動的に生成できます。それをコントロールする必要があります。とはいえ DataChannel でも同じような感じだったので気にならないと思います。
Stream を作ったらあとは送受信ですが送信は write で、read は onquicstream で上がってきた RTCQuicStream に waitForReadable や waitForWriteBufferedAmountBelow があるのでそれを使ってうまいことやっていく必要があります。
ここでお気付きかと思いますが QUIC と DataChannel は大きな差があります。DataChannel はリトライ回数やリトライ時間、順序などがいくつか決められたのから選べばよかったのですが、QUIC の場合はそうも行きません。
まず順番保証がしたかったら 1 ストリームしか使ってはいけません。複数ストリームを利用した場合は順番保証はされません。動的にガンガンストリームを作って送り続けるというのが問題ないため、順番保証をきにしないのであればサーバが許す限りストリームを作って送ることができます。
