カスケードSFU：WebRTCアプリケーションでのメディアのスケーラビリティと品質の改善

WebRTC用のメディアサーバーの展開には、スケーリング、つまり 1つのサーバーを使用するだけでなく、すべての会議ユーザーの遅延を最適化します。 「X会議のすべてのユーザーをサーバーYに送信する」という精神の単純なシャーディングは簡単に水平にスケーリングできますが、遅延の点では最適とはほど遠いです。 ユーザーに近いだけでなく、相互接続されているサーバー間で会議を配布することは、両方の問題の解決策のように思えます。 今日、私たちはJitsiのBoris Grozevからの詳細な資料の翻訳を準備しました：カスケードSFUの問題、アプローチの説明といくつかの困難、および実装の詳細。 Voximplantの会議でもSFUを使用していると言う価値があります 。 現在、SFUのカスケードに取り組んでおり、来年はプラットフォームに表示される予定です。









マウスニューロン。 NIHDイメージ（ CC-BY-2.0 ）



リアルタイム通信は、ネットワーク、帯域幅、遅延、パケット損失に非常に敏感です。 ビットレートの低下はビデオ品質の低下につながり、長いネットワーク遅延はエンドユーザーの長い遅延につながります。 パケットが失われると、音が断続的になり、ビデオのフリーズが発生する可能性があります（フレームスキップのため）。



したがって、会議ではエンドデバイス/ユーザー間の最適なルートを選択することが非常に重要です。 ユーザーが2人しかない場合は簡単です-WebRTCはICEプロトコルを使用して参加者間の接続を確立します。 可能であれば、参加者は直接接続します。それ以外の場合は、TURNサーバーが使用されます。 WebRTCはドメイン名を解決してTURNサーバーのアドレスを取得できるため、たとえばAWS Route53プロパティを使用して、DNSに基づいてローカルTURNを簡単に選択できます。



ただし、1つの中央メディアサーバーを介して複数の参加者をルーティングする場合、状況は複雑になります。 多くのWebRTCサービスは、選択的転送ユニット（SFU）を使用して、3人以上の参加者間でオーディオとビデオをより効率的に転送します。

星の問題

スタートポロジでは、すべての参加者がメディアストリームを交換する単一のサーバーに接続します。 サーバーの場所の選択は非常に重要です。すべての参加者が米国にいる場合、シドニーでサーバーを使用することはお勧めできません。









多くのサービスは、ほとんどの場合うまく機能するシンプルなアプローチを使用します。つまり、会議の最初の参加者により近いサーバーを選択します。 ただし、このソリューションが最適でない場合があります。 上の写真から3人の参加者がいると想像してください。 オーストラリア人（発信者C）が最初に会議に参加する場合、アルゴリズムはオーストラリアのサーバーを選択しますが、米国のサーバー1が最良の選択になります。 彼はほとんどの参加者に近い。



説明されているシナリオはそれほど頻繁ではありませんが、実際に発生します。 ユーザーがランダムな順序で接続されていると仮定すると、3人の参加者がいるすべての会議のwithで説明された状況が発生し、そのうちの1人は大きく削除されます。



別のより頻繁なシナリオ：異なる場所に2つのグループの参加者がいます。 この場合、接続順序は重要ではありません。リモートサーバーとメディアを交換することを余儀なくされる、密接に位置する参加者のグループが常に存在します。 たとえば、オーストラリアから2人の参加者（C＆D）とアメリカから2人の参加者（A＆B）。









サーバー1への切り替えは、C＆Dメンバーには最適ではありません。 サーバー2はA＆Bに最適ではありません。 つまり、使用されているサーバーに関係なく、リモート（=非最適）サーバーに接続された参加者が常に存在します。



しかし、単一のサーバー制限がない場合はどうでしょうか？ 各参加者を最も近いサーバーに接続できますが、これらのサーバーに接続するだけです。

解決策：カスケード

サーバーの接続方法の質問は延期します。 まず、効果がどうなるかを見てみましょう。









CとDの間のSFU接続は変更されていません-サーバー2は引き続き使用されますが、サーバーAは参加者AとBに使用され、これは明らかに優れています。 最も興味深いのは、たとえばAとC間の接続です。A<=>サーバー2 <=> Cの代わりに、ルートA <=>サーバー1 <=>サーバー2 <=> Cが使用されます。

為替レートへの暗黙の影響

SFUミックスには長所と短所があります。 一方では、上記の状況では、ネットワーク上の新しいジャンプが追加されると、参加者間の交換時間が長くなります。 一方、「クライアント」-「最初のサーバー」接続について話すときは、ホップバイホップの原則により、より低い遅延でメディアストリームを復元できるため、この時間は減少します。



どのように機能しますか？ WebRTCはRTP（通常はUDP経由）を使用してメディアを送信します。 これは、トランスポートが信頼できないことを意味します。 UDPパケットが失われた場合、その損失を無視するか、 RTCP NACKパケットを使用して再送信（再送信）を要求できます。選択はアプリケーションの良心によります。 たとえば、アプリケーションは、後続のフレームをデコードする必要があるかどうかに応じて、オーディオパケットの損失を無視し、一部の（すべてではない）ビデオパケットの再送信を要求できます。









RTPパケットの再送信、単一サーバー



カスケードがある場合、再送信はローカルサーバーに制限される可能性があります。つまり、各サイトで実行されます。 たとえば、ルートA-S1-S2-Cでは、AとS1の間でパケットが失われた場合、S1はこれに気付き、再送信を要求します。 S2とCの間の損失に似ています。また、サーバー間でパケットが失われた場合でも、受信側は再送信を要求する場合があります。









RTPパケットの再送信、2台のサーバー。 NACKはパケットを送信した直後に到着したため、サーバー2はパケット2を要求しないことに注意してください。



クライアントは、ジッタバッファを使用して、ビデオの再生を遅延させ、遅延/再送信パケットの受信を管理します。 バッファサイズは、パーティ間の交換時間に応じて動的に変化します。 ホップごとの再送信が発生すると、遅延が減少し、その結果、バッファーが小さくなる可能性があります。その結果、全体的な遅延も減少します。



簡単に説明すると、参加者間の交換時間が長くなっても、参加者間のメディア転送の遅延が減少する可能性があります。 実際にこの効果を研究することはまだありません。

カスケードSFUの紹介：Jitsi Meet Case

アラーム対 メディア

アラームを見てみましょう。 当初から、Jitsi Meetはシグナリングサーバー（ Jicofo ）とメディアサーバー/ SFUの概念を共有していました。 これにより、カスケードサポートの導入が比較的簡単になりました。 まず、すべてのシグナリングロジックを1か所で処理できます。 第二に、Jicofoとメディアサーバー間で既にシグナリングプロトコルがありました。 機能を少し拡張するだけで済みました。1つのシグナルサーバーに接続された複数のSFUを既にサポートしていたため、1つのSFUが多くのシグナルサーバーに接続する機能を追加する必要がありました。



その結果、2つの独立したサーバープールが登場しました。1つはjicofoインスタンス用で、もう1つはメディアサーバーインスタンス用です。図を参照してください。









異なるデータセンター間でカスケードが発生する可能性があるAWSでサーバーを整理する例。



システムの2番目の部分は、ブリッジ間通信です。 この部分をできるだけシンプルにしたかったので、ブリッジ間に複雑な信号はありません。 すべてのアラームはjicofoとjitsi-videobridgeの間を行き来します。 ブリッジ接続は、オーディオ/ビデオおよびデータリンクメッセージにのみ使用されます。

オクトプロトコル

この相互作用を管理するために、単純な固定長ヘッダーでRTPパケットをラップし、テキストメッセージを送信できるOctoプロトコルを採用しました。 現在の実装では、ブリッジはフルメッシュトポロジ（フルメッシュ）で接続されていますが、他のトポロジも可能です。 たとえば、中央サーバー（ブリッジのスター）または各ブリッジのツリー構造を使用します。



説明：Octoヘッダーでラップする代わりに、RTPヘッダー拡張を使用して、純粋な（S）RTPのブリッジ間でフローを作成できます。 Octoの将来のバージョンでは、このアプローチを使用できます。



2番目の説明：Octoは何の意味もありません。 最初は中央サーバーを使用したかったため、タコを思い出しました。 そのため、プロジェクトの名前が表示されました。







オクトヘッダー形式



Jitsiの用語では、ブリッジが複数のブリッジとの会議の一部である場合、追加のOctoチャネル（実際には、オーディオ用とビデオ用の1つのチャネル）があります。 このチャネルは、他のブリッジとの間でメディアを送受信します。 各ブリッジにはOctoの空きポート（デフォルトでは4096）が割り当てられているため、複数の会議を処理するには[会議ID]フィールドが必要です。



現時点では、プロトコルには組み込みのセキュリティメカニズムがなく、この責任を下位レベルに委任しています。 これは近い将来行うことですが、これまでのところ、ブリッジは安全なネットワーク（たとえば、別個のAWS VPCインスタンス）にある必要があります。

同時放送

Simulcastは、各参加者が異なるビットレートで複数のメディアストリームを送信できるようにし、ブリッジは必要なメディアストリームを決定するのに役立ちます。 これが正しく機能するために、すべてのサイマルキャストストリームをブリッジ間で転送します。 これにより、ローカルブリッジが新しいストリームを要求する必要がないため、ストリームをすばやく切り替えることができます。 ただし、これは、ブリッジ間トラフィックの観点から最適ではありません。 一部のスレッドはめったに使用されず、目的のない帯域幅のみをロードします。

アクティブメンバーの選択

また、会議のアクティブな参加者/講演者を購読する機会が欲しかった。 簡単であることが判明しました。各参加者にメイン参加者を独立して決定し、ローカルクライアントに通知するように教えました。 これは、決定が数回行われることを意味しますが、費用がかからず、いくつかのポイントを簡素化できます（たとえば、どのブリッジがDSIを担当し、メッセージルーティングを心配する必要があるかを決定する必要はありません）。

橋の選択

現在の実装では、このアルゴリズムは単純です。 新しい参加者が会議に参加するとき、Jicofoは自分に割り当てるブリッジを決定する必要があります。 これは、参加者の地域とブリッジの混雑に基づいて行われます。 同じ地域に無料の橋がある場合は、指定されます。 それ以外の場合、他のブリッジが使用されます。



Octoの詳細については、 ドキュメントを参照してください。

カスケードSFUを展開する

デプロイには、Amazon AWSのマシンを使用しました。 6つの地域にサーバー（アラームとメディア）がありました。

• us-east-1（ノースバージニア州）;
• us-west-2（オレゴン）;
• eu-west-1（アイルランド）;
• eu-central-1（フランクフルト）;
• ap-se-1（シンガポール）;
• ap-se-2（シドニー）。

メンバー地域を決定するために、地理参照されたHAProxyインスタンスを使用しました。 meet.jit.siドメインはRoute53によって管理され、HAProxyインスタンスに解決されます。これにより、送信されたリクエストのHTTPヘッダーにリージョンが追加されます。 ヘッダーは、 config.deploymentInfo.userRegion



変数の値として後で使用されます。この変数は、 /config.js



ファイルのおかげでクライアントで使用できます。



jitsiインターフェースは、診断とデモンストレーションのために、使用されているブリッジの数と特定のユーザーが接続されているユーザーを示します。 ローカルビデオの左上隅にカーソルを合わせると、サーバーの総数と接続しているサーバーが表示されます。 同様に、2番目の参加者のパラメーターを確認できます。 また、ブラウザと対話者のブラウザ間の交換時間も確認できます（パラメータE2E RTT）。









誰がどのサーバーに接続されているかを確認することで、カスケードが使用されているかどうかを確認できます。

おわりに

OctoはもともとA / Bテストとして登場しました。 最初の結果は良かったので、Octoは誰でも利用できます。 まだ多くのトラフィックが通過し、パフォーマンスを詳しく調べています。 また、これらの開発を使用して、さらに大きな会議をサポートすることも計画されています（1つのSFUでは不十分な場合）。