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

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

自分の立ち位置

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

WebTransport への理解

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

結論

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

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

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

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

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

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

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

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

技術的な知識

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

いつかでる Real World HTTP 第3版で HTTP/3 や WebTransport (over HTTP/3) について書いてくれるだろうからそれを待てば十分です。

メモ

Intel による Webcodecs / WebTransport

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

Media over QUIC

moq

Twitch が WebTransport を実験する話

Twitch の WebTransport 例は WebRTC 的な利用をする場合は参考にしてはならない。

https://datatracker.ietf.org/meeting/109/materials/minutes-109-webtrans-00

QUIC のカスタム実装を行っており、さらには WebTransport を配信と視聴に採用しようとしている話。

RTMP -> Twitch -> HLS
WebTransport -> Twitch -> WebTransport

ただフォールバック先を配信は RTMP 、視聴は HLS と捉えているため WebTransport のプロトコルを採用するがフォールバックは自分たちで頑張るという感じ。

WebRTC のような利用の場合はフォールバックはとても重要、 TURN を一切意識しなくて良い WebRTC は本当によくできている。

WebTransport の立ち位置

WebTransport over HTTP/3 で行く事が決まっため、 WebSocket over HTTP/2 の HTTP/3 版なんだな、くらいでいい。

フォールバック先は WebTransport over HTTP/2 の可能性が高そう

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

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