WebRTC - スケーラブルなライブストリームブロードキャスト/マルチキャスト 質問する

ここでかなり説明されているように、ここでやろうとしていることは、単純な旧式の WebRTC (厳密にはピアツーピア) では不可能です。前に述べたように、WebRTC 接続はセッションごとにデータを暗号化するために暗号化キーを再ネゴシエートするためです。そのため、ブロードキャスター (B) は、参加者の数だけストリームをアップロードする必要があります。

ただし、非常にシンプルでうまく機能する解決策があります。私はそれをテストしましたが、それは WebRTC ゲートウェイと呼ばれます。ヤヌスは良い例です。完全にオープンソースです（githubリポジトリはこちら）。

これは次のように機能します。放送局がゲートウェイ（Janus）に接続します。WebRTCを話すつまり、鍵のネゴシエーションが行われ、B は安全に (暗号化されたストリームを) Janus に送信します。

ここで、参加者が接続すると、WebRTC ネゴシエーション、セキュリティで保護されたキーなどのために再び Janus に接続します。今後、Janus は各参加者にストリームを返します。

これは、ブロードキャスター (B) がストリームを Janus に一度だけアップロードするだけで済むため、うまく機能します。これで、Janus は独自のキーを使用してデータをデコードし、生データ (つまり、RTP パケット) にアクセスして、各参加者にそれらのパケットを返送できます (Janus が暗号化を行います)。また、Janus をサーバーに配置すると、アップロード帯域幅が大きくなり、多くのピアにストリーミングできるようになります。

そう、それはするサーバーが関係しますが、そのサーバーは WebRTC に対応しており、それを「所有」します。Janus 部分を実装するので、データの破損や中間者攻撃を心配する必要はありません。もちろん、サーバーが侵害されない限りは。しかし、できることはたくさんあります。

incoming_rtp()使い方が簡単であることを示すために、Janus には、と呼ばれる関数がありincoming_rtcp()、これを呼び出すと、rt(c)p パケットへのポインターが提供されます。その後、各出席者にそれを送信できます (それらはsessionsJanus で非常に使いやすくなっている に格納されています)。incoming_rtp()関数の実装例についてはこちらをご覧ください、数行下パケットをすべての出席者に送信する方法を確認できます。ここRTP パケットを中継する実際の機能を確認できます。

すべてうまく機能し、ドキュメントも読みやすく理解しやすいです。「echotest」の例から始めることをお勧めします。これは最もシンプルで、Janus の内部動作を理解できます。echo test ファイルを編集して独自のファイルを作成することをお勧めします。冗長なコードが多数記述されるため、完全なファイルから始める方がよいでしょう。

楽しんでください！お役に立てれば幸いです。