WebRTC SFU 開発者からみた WebTrasnport の現状

定期的にアップデートしていきます

自分の立ち位置

• 商用 WebRTC SFU のプロトコルスタック実装経験あり
• QUIC プロトコルタック実装経験あり

WebTransport への理解

• WebTransport over HTTP/3 の知識はあり
• WebTransport over HTTP/2 の知識はあり

WebRTC 的な利用をする場合の結論

WebTrasnport を WebRTC 的な利用をする視点からの結論です。

WebTransport は WebRTC のような MediaChannel / DataChannel からみたら圧倒的に仕組みが足りてないので、
WebTransport の上にそれらの仕組みを作り込める必要があります。
これは Zoom が DataChannel 上に様々な仕組みを作り上げるのと同じことをやる必要があります。

実際 Media over QUIC のメーリングリストでは RTP over QUIC という話がでているくらいです。
結局メディア専用のプロトコルを自分たちで仕様を決め載せる必要がある。さらにブラウザから利用する場合、
プロトコル処理を自前で用意しなければならず、 WebAssembly などで解決しなければなりません。

すべてが WebRTC が実現していることを WebTransport 上で実現しようとするとあまりにも膨大な時間がかかります。

そもそも iOS / Android 向けのネイティブアプリへの対応はどうするのか、などもあります。
そのため、現時点というか当面は「体力があり、配信ビジネスで成果を出している」企業が利用していく技術です。

Media over QUIC としての利用する場合の結論

Twitch の Warp が Media over QUIC の一環として WebTransport 上に片方向配信プロトコルを実装しています。

WebRTC を採用しなかった理由は明確で ...

• レイテンシーを優先しすぎないでほしい
  • WebRTC はレイテンシーが最優先のため音声や映像のライブ配信には向いていない
• ストリーム単位で独自の優先順位をつけたい
  • WebRTC は凝り固まったプロトコルのため独自の優先順位はつけられない

以上の二つの理由により Warp では QUIC (WebTransport) を採用しています。この選択は間違いないと思います。

WebTransport でできて、WebRTC でできないこと

今のところ独自で何かをするという事以外はありません

• 独自コーデックを採用する
• 独自プロトコルを採用する
• 独自エラー訂正技術を採用する

技術的な知識

WebTrasnport は WebSocket の QUIC 版という認識で良い問題ありません。
QUIC はストリーム単位でしか再送の仕組みはないし、QUIC DATAGRAM 拡張についてはそれすらありません。

メモ

Intel による Webcodecs / WebTransport

まだ記事は出ていませんが WebAssembly で RTP パケタライザーを実現したと発表していました。

Media over QUIC

moq

フォールバック先は WebTransport over HTTP/2

draft-kinnear-webtransport-http2-02 - WebTransport using HTTP/2

フォールバックは「失敗する」「自分でがんばる(WebSocket など)」「WebTransport over HTTP/2」の 3 択にはなっている。