はじめに

W3C^[1] によって RTPTransport という新たな API が提案されています。これが WebRTC のカスタマイズ性を飛躍的に向上させる重要な API になると思われるため、現状わかることをまとめてみました。提案に至った背景もわかるような構成にしておりますので、以下のような方々にとって有用な記事となっていると思います。

WebRTC を利用した開発に携わっており、動向を知りたい方
WebRTC の概要を理解しており、課題や今後の方針についても理解しておきたい方

なお、本記事は二部構成になっています。これまでの背景から知りたいという方は初めから、RTPTransport の情報だけ得たいという方は二部のみお読みいただくのがオススメです。

忙しい方向け

RTPTransport を使用することで WebRTC のあらゆる要素をカスタマイズできるようになる
これまでよりも低レベルの API のため、難易度の高い手段になると思われる
現在は策定開始段階につき、実際にブラウザ上で試せるようになるのはもう少し先の話

これまでの背景

WebRTC は 2021 年に W3C 勧告を受けて標準化の宣言^[2] がされています。ここでは、一般的な通話のユースケース (Web 会議など) を満たせる形で一度標準化を行い、IoT や VR、Gaming などの新たなユースケースは WebRTC Extended Use Cases^[3] として策定を続けるということで整理がされました。

現在、 W3C の WebRTC WG では、これらのユースケースを解決するための手段を提案し、標準化することがミッションとなっています。

WebRTC の課題

標準化時点

WebRTC における映像/音声データは、通話を実現するためのエンコードや暗号化、輻輳制御等が自動的に行われた上で送信されます。これにより、アプリケーションはこれらの複雑な処理を意識せずにストリーミングを行うことができます。

WebRTC の処理パイプライン概要

ただし、標準化が行われた時点の WebRTC では上記の処理パイプラインの内容はカスタマイズできないため、特定のユースケースを満たせない場合があります。例えば、使用する中継サーバが信用できないので独自の暗号化をかけたいというユースケースがあっても、そのような API は存在しないため実現は難しい状況でした。

現在

現在は、特定のユースケースに対応すべく、処理パイプラインをカスタマイズするための API が提供され始めています。

処理パイプライン追加の概要 (受信側も同様)

1つは MediaStreamTrack Insertable Media Processing using Streams というドラフトの中で定義されている MediaStreamTrackProcessor と VideoTrackGenerator という API です。MediaStreamTrackProcessor を使用すると WebRTC によってエンコードされる前の画像/音声データを取り出すことができ、アプリケーションで任意の処理を行うことができます。任意の処理を行った後は VideoTrackGenerator により元のパイプラインへと返します。これによって画像や音声に対して AI 処理を実行した上で送信するといったユースケースを満たすことができます。

もう1つは WebRTC Encoded Transform というドラフトです。こちらで定義された API を使用することでエンコードされた後のデータを取り出すことができます。これを活用し、例えばエンコード後のデータに独自の暗号化を行うことで、E2EE (End-to-End Encryption)^[4] 等のユースケースを満たすことができます。

ただし、これらの方法でもパイプラインに処理を追加することしかできないため、任意のコーデックを使用したり独自の輻輳制御を行ったりすることは難しい状況です。

RTPTransport とは

この記事の本題の RTPTransport とは、W3C の WebRTC WG によって提案され、その構想について議論が進められている最中の、WebRTC の新たな API です。2023/04 の Meeting の議題の一つとして登場し、2023/10 に webrtc-rtptransport リポジトリが公開されています。

概要

Web アプリケーションに WebRTC の送信機能の制御を与えることにより、様々な要素のカスタマイズを可能とすることが目的となっています。

2023 Apr Meeting にて使用された概要図

Web アプリケーション側でメディアをエンコードし、それらを RTP としてパケット化して RTPTransport に渡すことで、WebRTC のストリームとして Peer へと送信する事ができます。つまり、これまで WebRTC が行っていたメディアの用意や制御のプロセスが開放され、Web アプリケーション側で実装可能になるというものです。

explainer にて以下のようなコード例も提供されています。

カスタマイズされたパケットを送信する例

const pc = new RTCPeerConnection({encodedInsertableStreams: true});
const rtpTransport = pc.createRtpTransport();
pc.getSenders().forEach((sender) => {
  pc.createEncodedStreams().readable.
      pipeThrough(createPacketizingTransformer()).pipeTo(rtpTransport.writable);
});

function createPacketizingTransformer() {
  return new TransformStream({
    async transform(encodedFrame, controller) {
      let rtpPackets = myPacketizer.packetize(frame);
      rtpPackets.forEach(controller.enqueue);
    }
  });
}

RTCPeerConnection に対して createRtpTransport() で RTPTransport を用意し、アプリケーション側で独自に実装した myPacketizer によってパケット化された RTP パケットを渡すことで送信ができるようです。

なお、現在はまだ仕様の策定が始まったばかりで、ドラフトも用意されていないような状態です。そのため、上記のようなコードをブラウザ上で実際に試すことができるようになるのはもう少し先の話となります。

RTPTransport によってできること

RTPTransport 使用時のパイプラインは下図のような形が一般的になるだろうと思われます。

RTPTransport のパイプライン (受信側も同様)

ここで、VideoFrame や AudioData は MediaStreamTrackProcessor 等によって取得が可能なデータ形式なので、前述のようなメディアの処理は可能です。図のようにアプリケーションからカスタマイズ可能な範囲が大きく広がることで、以下のようなことができるようになります。

エンコードのカスタマイズ

エンコードに WebCodecs を活用することで、ブラウザが実装しているコーデックの中からユースケースに応じて選択し、使用することができます。また、図のパイプラインとは異なりますが、WebCodecs を使用せずに独自でエンコーダを実装することもできるため、ブラウザががまだサポートしていない Lyra のような、AIコーデックを採用することも可能です。
これにより、WebRTC で使用できるコーデックよりも圧縮効率の良いものを採用したり、エンコード時のパラメータ (キーフレームや解像度等) を変更することでユースケースに応じて品質と安定性のトレードオフを調整できるようになります。

パケット化のカスタマイズ

RTP へのパケット化もアプリケーション側でカスタマイズできるので、RTPTransport からビットレートのフィードバックを受け取りながら独自の輻輳制御を行ったり、独自の FEC (前方誤り訂正) や RTX (再送) を実装することができます。
例えば、FEC を強固にすることでパケロスに対してロバストな伝送を行うことができるので、重要な会議のようなユースケースで今まで以上に安定した通話を行うアプリケーションを開発することもできるようになると思われます。
また、ヘッダを拡張することもできるので、アプリケーションが使用する独自のメタデータを RTP に乗せることもできたりします。

その他

これらに加え、メディアを受信する際に使用するジッタバッファのサイズをカスタマイズすることでリアルタイム性と安定性のトレードオフを調整したり、RTCP メッセージの頻度を調整することでパケロス等の情報のフィードバックタイミングを早めたりすることもできます。
さらに、RTP のフォワーディングも想定されているため、VoIP や IP カメラといった既存の RTP システムのストリームを転送するという使い方もできるようになると思われます。

上記により、パイプラインのカスタマイズ性が乏しいという課題が解決され、これまでは満たせなかった Extended Use Cases の一部を実現できるようになることが期待されています。

WebTransport との差別化点

WebCodecs 等で自由にエンコードして送信できるというコンセプトは WebTransport の特徴と良く似ています。
Meeting の中でも WebTransport と競合するのではないか？という懸念が示されましたが、RTPTransport には以下のような差別化点が存在することが説明されました。

P2P 接続が可能 (WebTransport は Client-Server 前提)
リアルタイム通信向けの輻輳制御が可能 (WebTransport ではまだ用意されていない)
既存の RTP エンドポイントとの相互運用が可能

一番下は少しわかりにくいですが、RTPTransport では RTP のフォワーディングができるので、RTP ベースで運用されている既存のシステムとの相互運用が狙えることを差別化点として挙げていると推察できます。

難しいと思われる点

ここまで RTPTransport の良いところを紹介してきましたが、懸念すべき点もあります。

API を使用する難易度

Web アプリケーション側で RTP (+ RTCP) を組み立てる必要があるので、既存の API と比べると低レベルな API となります。扱わなければならないパラメータも非常に多くなり、使用する際の難易度は高くなると思われます。

2023 Sep Meeting (TPAC 2023) にて紹介された必要パラメータ

もちろん、これまでの API がなくなることはなく、それらと併用できるものとする想定で議論が進んでいます。そのため、RTPTransport はカスタマイズが必要な開発者のみが使用する上級者向けの API となると思われます。

WebTransport との切り分け

いくら WebTransport との差別化点があるとはいえ、WebTransport と被る要素も多くある点が気になります。現在 IETF^[5] の MoQ WG では WebTransport を活用してメディアを送信するためのプロトコルである MOQT (Media Over QUIC Transport) の仕様を策定している最中です。IETF 側と W3C 側でどのような議論がされてどのような整理に落ち着くか注目したいところです。

参考にした Meeting

2023 Apr Meeting: [スライド][議事録]
2023 May Meeting: [スライド][議事録]
2023 Sep Meeting (TPAC 2023): [スライド][議事録]

まとめ

RTPTransport が新たに公開されることにより WebRTC のカスタマイズ性が向上し、これまで以上に様々なユースケースに対して使いやすくなると思われます。ただし、これまでブラウザ側で行っていた様々な制御をアプリケーション側で実装する必要があるので、RTPTransport を使用する場合は開発難易度が高くなりそうな点は注意が必要です。

API の公開を期待して待ちたいですが、WebTransport (MOQT) とのユースケースの切り分けがどのように整理されていくか等といった周囲の動向も注視しておきたいところです。

脚注

World Wide Web Consortium。Web 技術の標準化を行う団体。 ↩︎
当初は WebRTC 1.0 という名称で標準化されたが、2023/03 のリリースにて 1.0 が外れている。 ↩︎
当初は WebRTC-NV Use Cases という名称だったが、2023/04 名称が変更されている。 ↩︎
送信者側で多重に暗号化をかける手法。信頼性の低い中継サーバで暗号化が解かれることを避ける目的で利用される。 ↩︎
Internet Engineering Task Force。インターネット上で使用されるプロトコルの標準化を行う団体。 ↩︎

Discussion