在 WebRTC 會議中，虛擬媒體串流是由選擇性轉送單元 (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。這個值在使用者離開前會保持不變。
由於 SSRCs 數量在整個 Meet Media API 工作階段中保持不變，因此有以下三種可能情況：
參與者人數超過可用 SSRCs：
Meet 會透過三個 SSRC 傳輸音量最大的三位使用者。由於每個 RTP 串流都有專屬的 SSRC，因此串流之間不會混雜。
圖 1. Meet 會在三個 SSRC 中傳輸音量最大的三個人聲。 如果會議中的任何原始串流不再是音量最大的串流，Meet 會將構成 SSRC 的 RTP 封包切換為音量最大的串流。
圖 2. Meet 會將 RTP 封包切換給新的最大聲者。 活躍參與者人數少於三個音訊 SSRC：
如果可用的 SSRC 數量多於會議中的串流數量，Meet 會將所有可用的音訊封包對應至專屬的 SSRC。任何未使用的 SSRC 仍可供使用，但不會傳輸 RTP 封包。
圖 3. 將地圖可用的音訊封包對應至專屬的 SSRC。 活躍參與者人數等於三個音訊 SSRC：
如果參與者人數與可用 SSRC 數量相同，每位參與者的媒體都會對應至專屬 SSRC。只要這個特定情境持續存在，這些對應就會持續存在。
圖 4. 將每位參與者的媒體對應至專屬 SSRC。