WebRTC、SFU、音声コーデックをやさしく解説
WebRTCが音声を運ぶ仕組み、Opusが音声を圧縮する仕組み、グループ動画にSFUが必要になる場面を解説。Voxalのアーキテクチャと RFC 参照付きの開発者向けガイドです。
WebRTCはブラウザ間で音声と映像をやり取りし、Opusのようなコーデックは音声を回線に載せられるサイズに圧縮し、SFU(Selective Forwarding Unit)は大人数の通話で各参加者の映像をほかの全員に転送するサーバーです。 この3つを理解すれば、マイクからリモートのスピーカーまでの間で起きていることの大半が説明できます。
このガイドは、シグナリング、ICE、STUNとTURN、RTP、Opus、そしてピアツーピアのメッシュとSFUのトレードオフといった仕組みを知りたい開発者や好奇心旺盛な読者に向けたものです。最後に、Voxalがこれらをどう組み合わせているかを紹介します。音声はピアツーピアのまま、カメラと画面共有にはSFUを使えます。概念だけ知りたい場合は、まずピアツーピア音声チャットとはをご覧ください。
1. WebRTCとは?
WebRTCは、リアルタイムの音声、映像、データ通信のための標準規格とブラウザAPIの集合です。
これにより、開発者はあらゆる転送方式やセキュリティ機構をゼロから実装しなくても、対応デバイス同士でメディア接続を確立できます。
WebRTCは単一のプロトコルではありません。複数のコンポーネントが連携して動作します。
シグナリング
2台のデバイスがメディア接続を確立するには、まずセッションと接続能力に関する情報を交換する必要があります。
この手順をシグナリングと呼びます。シグナリングの方式はアプリケーションが自由に選べます。WebRTCが唯一のシグナリングサーバーやシグナリングプロトコルを定めているわけではありません。
Voxalはシグナリングを使って、ルームの参加者管理と接続の確立を調整します。シグナリングの経路はメディアの経路とは別です。
ICE、STUN、TURN
デバイスの多くはルーター、ファイアウォール、ネットワークアドレス変換(NAT)の内側にあります。そのため、使える接続経路を見つけるのは、2つのグローバルIPアドレスをつなぐ場合よりも複雑になりがちです。
WebRTCは、Interactive Connectivity Establishment(ICE)を使って、候補となる接続経路を収集してテストします。
- STUNは、デバイスが公衆網から自分がどう見えるかを知る手助けをします。
- TURNは、適切な直接接続を確立できないときに中継経路を提供します。
TURNリレーは暗号化されたメディアトラフィックを転送するだけです。メディア接続を終端して選択的にメディアストリームを転送するSFUとは別物です。
直接接続が望ましいことは多いものの、接続性を保つうえでリレーが欠かせない場合もあります。
RTPと安全なメディア転送
リアルタイムメディアは、一般にReal-time Transport Protocol(RTP)で転送され、制御とレポートにはRTCPが併用されます。
WebRTCはメディアの保護にセキュアRTP(SRTP)を使います。転送レイヤーはパケットの配送を担い、コーデックは音声や映像そのものをどう表現するかを決めます。
両者の役割は別です。コーデックはネットワーク接続を確立せず、ネットワーク接続は音をどう圧縮するかを決めません。
2. 音声コーデックとは?
コーデックはメディアをエンコードおよびデコードします。音声通信では、了解度と許容できる音質を保ちながら、音声を効率よく表現するのが役割です。
圧縮しない生の音声をそのまま送ると、音声アプリケーションに必要な帯域幅をはるかに上回ることがあります。
コーデックは、次のような要素の間でトレードオフを取ります。
- 音質と音声の了解度。
- ビットレートと帯域幅の使用量。
- エンコードとデコードの複雑さ。
- 遅延とフレーム長。
- ネットワーク状況が変化したときの挙動。
あらゆる用途に最適な唯一のコーデックは存在しません。音楽ストリーミング、電話、ゲーム内チャット、リアルタイムのグループ会話では、優先事項がそれぞれ異なります。
Opusが広く使われる理由
Opusは、VoIP、ビデオ会議、ゲーム内チャットなどのために設計されたインタラクティブ音声コーデックです。
幅広いビットレート、サンプリングレート、フレーム長に対応しています。この柔軟性により、音声通話にも、より高い品質が求められるオーディオ用途にも向いています。
また、WebRTCの音声コーデック要件では、Opusは WebRTC エンドポイントが実装必須とされる音声コーデックでもあります。
だからといって、すべてのWebRTC接続が常にOpusを使うわけではありません。実際のコーデックは、参加するエンドポイント同士がネゴシエーションした能力によって決まります。
Voxalでは、文書化されているアーキテクチャ上、ブラウザのWebRTC音声パイプラインがデフォルトでOpusを使います。エンコード、転送、デコードの多くの処理はブラウザが担います。
リアルタイム音声アプリケーションでは、コーデックは体験の一部にすぎません。マイクの品質、音声処理、パケットロス、ネットワークレイテンシー、ジッターバッファ、デバイスの再生品質もすべて重要です。
3. SFUとは?
SFUはSelective Forwarding Unit(選択的転送ユニット)の略です。
SFUは、グループビデオ通話を支えるためによく使われるメディアサーバーです。すべての参加者がほかの全員に個別の映像ストリームを直接送る代わりに、各参加者はSFUにメディアを送り、SFUが適切なストリームをほかの参加者に転送します。
6人が参加するルームで、全員がカメラ映像を送っている場面を考えてみましょう。
完全なピアツーピアのメッシュでは、各参加者が自分の映像をほかの5人にアップロードする必要があります。サーバー経由の転送トポロジーでは、各参加者はSFUに1本のストリームを送るだけで、配信はSFUが担います。
これにより、参加者が維持しなければならない送信ストリームの数を大幅に減らせます。
SFUは実際に何をするのか?
SFUは通常、エンコード済みのメディアストリームを受信し、それを選択的に転送します。実装やネゴシエーションされた機能によっては、受信者ごとに送るストリームや品質レイヤーを選ぶこともあります。
たとえば、小さなサムネイルで見ている参加者には、話者を全画面で表示している人と同じ映像品質は必要ないかもしれません。
SFUを使えば、送信者がそれぞれ全受信者に個別のストリームを送らなくても、こうした要件の違いを管理しやすくなります。
ただし、SFUは無料ではありません。インフラ、サーバー帯域、運用コストがかかり、メディア経路にもう1つ構成要素が増えます。
SFUはTURNリレーとはプライバシーモデルも異なります。SFUはメディア転送を終端し、メディアを選択的に転送するため、受信したメディアに技術的にはアクセスできます。参加者とSFUの間の暗号化だけでは、そのSFUに対するエンドツーエンドの機密性は確保できません。
4. ピアツーピアメッシュとSFUの比較
2つのアーキテクチャは、似ていながら異なる問題を解決します。
ピアツーピアメッシュ
各参加者が、ほかの参加者とそれぞれメディア接続を確立します。
利点:
- 直接のメディア経路を使える。
- メディアを再配信する中央メディアサーバーが不要。
- 小規模なルームなら、メディア転送サービスなしで動作する。
トレードオフ:
- 各送信者が、ほかの全参加者に個別のストリームをアップロードする必要がある。
- ルームが大きくなるほどメディア接続の数が増える。
- アップロード帯域と接続管理が制約になりうる。
SFUベースの配信
各参加者が中央の転送サービスにメディアを送り、そのサービスがほかの参加者に配信します。
利点:
- 多くのグループビデオのシナリオで、より効率的に配信できる。
- 送信者が全受信者に別々のコピーをアップロードする必要が減る。
- 受信者が受け取る映像ストリームや品質レイヤーをより細かく制御できる。
トレードオフ:
- サーバーインフラと帯域のコストが追加でかかる。
- メディア経路に仲介者が入る。
- プライバシーと信頼のモデルが、直接のピアツーピア通信とは異なる。
重要なのは、すべてのメディアタイプに同じトポロジーを使わなければならないと決めつけないことです。音声と映像では、トラフィックのパターンも要件も異なります。
5. Voxalが音声をピアツーピアに保ちつつ、映像にはSFUを使える理由
Voxalは、音声と、カメラや画面共有の映像を分けて扱います。
音声は常にピアツーピアのままです。オプションの映像用SFUを経由することはありません。
これは意図的なアーキテクチャ上の判断です。音声は中核となるコミュニケーション機能であり、VoxalはSFUを音声配信の中心的なサービスとして使いません。
カメラや画面共有の映像は事情が異なります。大きなルームでは、完全なピアツーピアのメッシュだと、各参加者が複数の映像ストリームをアップロードしなければなりません。参加者が増えるほど、その負担は大きくなります。
そのためVoxalは、設定されたルーティング設定で許可されていて、かつルームの規模がメッシュの現実的な限界を超えている場合に、映像と画面共有にCloudflareのRealtime SFUを使えます。
ルーティング設定は次のように働きます。
- 大規模ルームではリレーを許可: ルームがピアツーピアの映像トポロジーとして無理のない規模を超えると、VoxalはSFUを使えます。
- 直接接続を優先: Voxalはまずピアツーピアを試み、メッシュが適さなくなったときはリレーを許可する前に確認します。
- 直接接続のみ: 大きなルームですべての直接接続の確立に苦労する場合でも、映像と画面共有は決してSFUを使いません。
これらの設定が影響するのは映像と画面共有であり、音声には影響しません。
なぜすべてを同じサーバー経由にしないのか?
最適なトポロジーは、運ぶトラフィックの種類によって変わるからです。
音声ストリームは、一般にカメラのストリームよりずっと小さくなります。音声を中央の転送サービス経由にすると、Voxalが選んだ音声アーキテクチャにとって不要なのに、インフラとプライバシーの面で別のトレードオフを抱えることになります。
映像は帯域の要求が大きく、グループの人数が増えるほどサーバー支援による配信の恩恵が大きくなります。
両者を分けることで、Voxalはピアツーピアの音声モデルを保ちながら、グループ映像にはよりスケールしやすい選択肢を提供できます。
6. プライバシーにとっての意味
ネットワーク用語は、特定のレベルのプライバシーを自動的に保証するかのように使われることがあります。実際にはそうではありません。
ピアツーピアの音声とは、音声メディアが中央メディアサーバーを経由しないという意味です。ただし、シグナリングサーバーは接続を調整し、関連するメタデータを処理することがあります。
TURNリレーは、暗号化されたメディアをデコードせずに転送します。これに対してSFUは、ストリームを選択的に転送するためにメディア転送を終端し、受信した映像に技術的にはアクセスできます。
だからこそ、Voxalの使い分けが重要です。
- 音声はピアツーピアのままで、必要に応じて暗号化されたTURNリレーを使う。
- カメラと画面共有の映像は、ルーティング設定によっては、大きなルームでSFUを使うことがある。
- ローカルのバーチャル背景処理は送信者のデバイス上で行われますが、それだけですべての映像接続が直接だとは限りません。
アプリケーションを「サーバーレス」と形容するだけより、実際のメディア経路を理解するほうがずっと役に立ちます。
7. まとめ
リアルタイム通信アプリケーションは、独立した複数のレイヤーを組み合わせています。
- シグナリングが、参加者と接続のセットアップを調整する。
- ICE、STUN、TURNが、使えるネットワーク経路の確立を助ける。
- WebRTCとセキュアRTP転送が、リアルタイムメディアを運ぶ。
- Opusのようなコーデックが、音声を効率よく表現する。
- ネットワークトポロジーが、メディアがピア間を直接流れるか、転送サービスを経由するかを決める。
Voxalの設計は、これらの選択を音声と映像で別々に適用しています。その結果が、音声はピアツーピアのままで、大きなルームでは映像と画面共有にオプションのサーバー支援転送を使える、音声重視のアーキテクチャです。
こうした区別は、リアルタイム通信システムを設計するうえで重要です。目標は、単にサーバーを最小化したり直接接続を最大化したりすることではありません。レイテンシー、帯域幅、信頼性、スケーラビリティ、プライバシーの間で、意図的にトレードオフを選ぶことです。
Voxalを試す
Voxalは、ピアツーピア音声チャット、push-to-talk(押している間だけ話せる機能)、ハンズフリーモード、ノイズ抑制、そしてオプションの映像と画面共有を組み合わせています。
ブラウザでVoxalを試すことも、オープンソースのVoxalリポジトリで実装を確認することもできます。
関連記事: ピアツーピア音声チャットとは? · push-to-talkとは? 実践ガイド · Voxalの映像ルーティングに関するドキュメント
