在 WebRTC 會議中，虛擬媒體串流是指由 Selective Forwarding Unit (SFU) 產生的媒體串流，用於匯總及發布多位與會者的媒體。與直接對等媒體串流不同，後者會在大型會議中建立複雜的網狀連線，而虛擬媒體串流則可簡化拓樸。SFU 會接收來自每位參與者的個別媒體串流，並有選擇地將有效或相關的串流轉送給其他參與者，將這些串流多路傳送至較小的固定外寄虛擬媒體串流組合。
這種做法可減少每位參與者需要處理的同時傳入串流數量，降低處理和頻寬需求。每個虛擬串流一次只能包含一位參與者的媒體，並由 SFU 根據講者活動或影片指派等因素動態調整。參與者會收到這些虛擬串流，有效地查看會議的組合檢視畫面，而不需要管理其他參與者的個別串流。虛擬媒體串流提供的這項抽象化功能，對於將 WebRTC 會議擴大至大量參與者而言至關重要。
如要接收音訊，用戶端必須提供三個音訊媒體說明，建立三個本機音訊收發器。如要接收影片，用戶端必須提供一到三個影片媒體描述，並建立相應數量的影片收發器。
接球員
每個由用戶端擁有的收發器都有專屬的 RtpReceiver 和專屬的「媒體音軌」，可接收 Meet 伺服器的音訊 RTP 串流。
每個音軌都有專屬 ID，並從該特定媒體來源接收專屬的 RTP 封包串流。舉例來說，音軌 A 可能會接收來自 production-1 的音訊，而音軌 B 則會接收來自 production-2 的音訊。
SSRC
每個 RTP 封包都有一個同步來源 (SSRC) 標頭值，可將其連結至特定音軌。
透過 Meet Media API 的音訊工作階段會使用三個不同的媒體串流，每個串流都有各自的靜態 SSRC。一旦建立，這些 SSRC 值在工作階段期間就不會變更。
虛擬串流
Meet Media API 會使用虛擬媒體串流。這些值在整個工作階段中都不會變更，但封包來源可能會變更，以反映最相關的動態消息。虛擬媒體串流的音訊和視訊行為相同。
RTP 封包標頭中的貢獻來源 (CSRC) 會標示 RTP 封包的實際來源。當參與者加入會議時，Meet 會為他們指派專屬的 CSRC。這個值會保持不變，直到使用者離開為止。
由於 SSRC 數量在 Meet Media API 工作階段中保持不變，因此可能出現以下三種情況：
參與者人數多於可用的 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。