WebRTC 会議のコンテキストでは、仮想メディア ストリームは、選択的転送ユニット（SFU）によって生成され、複数の参加者からのメディアを集約して配信するメディア ストリームです。大規模な会議で複雑な接続メッシュを作成する直接のピアツーピア メディア ストリームとは異なり、仮想メディア ストリームはトポロジを簡素化します。SFU は各参加者から個々のメディア ストリームを受信し、アクティブなストリームまたは関連するストリームを選択的に他の参加者に転送し、送信される仮想メディア ストリームの小さな固定セットに多重化します。
このアプローチにより、各参加者が処理する必要がある同時受信ストリームの数を減らし、処理と帯域幅の要件を削減できます。各仮想ストリームには、一度に 1 人の参加者のメディアを含めることができます。これは、スピーカーのアクティビティや動画の割り当てなどの要素に基づいて SFU によって動的に調整されます。参加者はこれらの仮想ストリームを受信し、他の参加者の個々のストリームを管理することなく、会議の合成ビューを効果的に表示できます。仮想メディア ストリームによって提供されるこの抽象化は、WebRTC 会議を多数の参加者にスケーリングするうえで重要です。
音声を受信するには、クライアントが正確に 3 つのオーディオ メディアの説明を提供し、3 つのローカル オーディオ トランスシバーを作成する必要があります。動画を受信するには、クライアントが 1 ～ 3 つの動画メディアの説明を提供し、その数の動画トランシーバーを確立する必要があります。
レシーバー
各クライアント所有のトランシーバーには、専用の RtpReceiver と、Meet サーバーから音声 RTP ストリームを受信する専用の「メディア トラック」があります。
各トラックには一意の ID があり、その特定のメディアソースから独自の RTP パケット ストリームを受信します。たとえば、トラック A は production-1 から音声を受信し、トラック B は production-2 から音声を受信します。
SSRC
各 RTP パケットには、特定のトラックに関連付けられた同期ソース（SSRC）ヘッダー値があります。
Meet Media API を介した音声セッションでは、それぞれに独自の静的 SSRC を持つ 3 つの個別のメディア ストリームが使用されます。確立されたこれらの SSRC 値は、セッションの存続期間中は変更されません。
バーチャル ストリーム
Meet Media API は仮想メディア ストリームを使用します。これらはセッション全体で静的ですが、最も関連性の高いフィードに合わせてパケットの送信元が変更される場合があります。仮想メディア ストリームは、音声と動画で同じ動作をします。
RTP パケット ヘッダーのContributing Source（CSRC）は、RTP パケットの真の送信元を示します。Meet では、会議に参加する各参加者に固有の CSRC が割り当てられます。この値は、ユーザーが離れるまで一定です。
SSRC の数は Meet Media API セッション全体で一定であるため、次の 3 つのシナリオが考えられます。
利用可能な SSRC よりも参加者が多い場合:
Meet は、3 つの SSRC にわたって最も音量の大きい 3 人の音声を送信します。各 RTP ストリームは独自の専用 SSRC にあるため、ストリーム間で混在することはありません。
図 1. Meet は、3 つの SSRC にわたって最も音量の大きい 3 人の音声を送信します。 会議の元のストリームのいずれかが最も音量の大きいストリームではなくなった場合、Meet は SSRC を構成する RTP パケットを最も音量の大きいストリームに切り替えます。
図 2. Meet は、RTP パケットを新しい最も大きな音量の参加者に切り替えます。 アクティブな参加者数が 3 つの音声 SSRC より少ない:
会議内のストリーム数よりも多くの SSRC が使用可能なシナリオでは、Meet は使用可能な音声パケットを独自の SSRC にマッピングします。未使用の SSRC は引き続き使用可能で、RTP パケットは送信されません。
図 3. Meet は、利用可能なオーディオ パケットを独自の SSRC にマッピングします。 アクティブな参加者数は 3 つの音声 SSRC に等しい:
参加者数が同じで利用可能な SSRC があるシナリオでは、各参加者のメディアが専用の SSRC にマッピングされます。これらのマッピングは、この特定のシナリオが存続する限り保持されます。
図 4. Meet は、各参加者のメディアを専用の SSRC にマッピングします。