在 WebRTC 会议环境中，虚拟媒体流是选择性转发单元 (SFU) 生成的媒体流，用于汇总和分发来自多个参与者的媒体。与直接点对点媒体串流不同（这会在大型会议中创建复杂的连接网格），虚拟媒体串流会简化拓扑。SFU 会接收来自每个参与者的各个媒体串流，并选择性地将有效或相关的串流转发给其他参与者，将其多路复用到较小的一组固定的传出虚拟媒体串流。
这种方法可减少每个参与者需要处理的并发传入数据流的数量，从而降低处理和带宽要求。每个虚拟直播一次只能包含一位参与者的媒体内容，由 SFU 根据讲者活动或视频分配等因素进行动态调整。参与者会收到这些虚拟串流，从而有效地看到会议的组合视图，而无需管理来自每个其他参与者的各个串流。虚拟媒体流提供的这种抽象对于将 WebRTC 会议扩展到包含大量参与者至关重要。
如需接收音频，客户端必须提供恰好三个音频媒体描述，从而创建三个本地音频收发器。如需接收视频，客户端必须提供 1 到 3 个视频媒体描述，以建立相应数量的视频收发器。
接收器
每个客户端拥有的收发器都有专用的 RtpReceiver 和专用的“媒体轨道”，用于接收来自 Meet 服务器的音频 RTP 流。
每个轨道都有一个唯一的 ID，并从该特定媒体源接收自己的 RTP 数据包流。例如，轨道 A 可能会从 production-1 接收音频，而轨道 B 会从 production-2 接收音频。
SSRC
每个 RTP 数据包都有一个 Synchronization Source (SSRC) 标头值，将其与特定轨道相关联。
通过 Meet Media API 的音频会话使用三个不同的媒体串流，每个串流都有自己的静态 SSRC。建立后，这些 SSRC 值在会话生命周期内将永远不会更改。
虚拟串流
Meet Media API 使用虚拟媒体串流。这些值在整个会话期间保持不变，但数据包的来源可能会发生变化，以反映最相关的 Feed。虚拟媒体串流对音频和视频的行为方式相同。
RTP 数据包标头中的贡献来源 (CSRC) 用于标识 RTP 数据包的真实来源。Meet 会在会议参与者加入时为其分配各自唯一的 CSRC。此值在用户离开之前会保持不变。
由于整个 Meet Media API 会话中的 SSRC 数量保持不变，因此以下是三种可能的情况：
参与者人数超出可用的 SSRC 数量：
Meet 会从三个 SSRC 中传输声音最响亮的三个人。由于每个 RTP 数据流都有自己的专用 SSRC，因此数据流之间不会混合。
图 1. Meet 会从三个 SSRC 中传输声音最响亮的三个人。 如果会议中的任何原始串流不再是最响亮的串流之一，Meet 会将构成 SSRC 的 RTP 数据包切换为最响亮的串流。
图 2. Meet 会将 RTP 数据包切换到新的音量最大者。 活跃参与者数量少于三个音频 SSRC：
如果可用的 SSRC 数量多于会议中的串流数量，Meet 会将任何可用的音频数据包映射到自己的唯一 SSRC。所有未使用的 SSRC 仍处于就绪状态，但不会传输任何 RTP 数据包。
图 3. Meet 会将可用音频数据包映射到其自己的唯一 SSRC。 活跃参与人数等于三个音频 SSRC：
对于参与者数量和可用 SSRC 数量相同的情况，系统会将每个参与者的媒体映射到专用的 SSRC。只要此特定场景持续存在，这些映射就会保留。
图 4. Meet 会将每位参与者的媒体映射到专用的 SSRC。