当只有一对用户进行视频通话时，无需中间服务器介入。然而，当参与者增加到十人时，就需要使用服务器来管理流媒体。
在传统的点对点通话中，每添加一个参与者，每个浏览器就需要为每个参与者编码并上传视频流，这在参与者达到六七个时会导致大多数笔记本电脑和家庭网络不堪重负。WebRTC SFU通过让每个参与者上传一条流到服务器，再由服务器转发给其他所有参与者，解决了这一问题。
Google Meet和Discord均采用了SFU技术，开源的LiveKit、mediasoup、Janus和Jitsi等技术栈也是基于SFU构建。
简单来说，SFU可以保持每个参与者的上传带宽恒定，将计算成本转化为带宽成本，并且当大多数观众只是观看时，它就不那么适合了。
WebRTC SFU是一种媒体服务器，它接收来自每个参与者的音频和视频流，并向其他参与者转发选定的流，而无需解码或重新编码媒体。每个客户端上传一条流（或几条层流），并下载所需的流。
“选择性”转发意味着SFU会根据订阅者的带宽、屏幕布局和说话者等因素，决定向每个订阅者发送哪些流及其质量。
2015年11月发布的RFC 7667定义了这种模式，称为选择性转发中间设备（Selective Forwarding Middlebox）。业界普遍使用“SFU”这一术语。
在标准的WebRTC堆栈之上添加SFU。客户端仍然使用RTCPeerConnection、ICE、DTLS和SRTP。区别在于，远程对等方是服务器，而不是另一个浏览器。
连接超过两个WebRTC参与者有三种方法，选择哪种方法影响着带宽费用、服务器CPU费用和参与者数量。
在网状网络中，每个参与者直接与每个其他参与者建立对等连接。没有媒体服务器参与，只有信令服务器交换SDP和ICE候选。
这种方式运行成本最低，延迟也最小，但也很快崩溃，因为每个客户端都为每个对等方编码并上传视频。
多点控制单元（MCU）解码每个传入的流，将它们合成为一个视频流（网格或发言者布局），重新编码它，然后给每个参与者发送一条流。
客户端的处理工作较少，但服务器需要进行大量的视频解码和编码，这会消耗大量CPU资源，增加延迟，并限制所有观众只能使用相同的布局。
相比之下，SFU则折中了这两种方法。客户端上传流的方式与MCU类似，但服务器只转发数据包，类似于路由器。每个客户端解码多个流，并根据应用程序的需求进行布局。
假设每个摄像机流为1.5 Mbps，有10人参与通话。在网状网络中，大多数家庭网络无法维持13.5 Mbps的上行带宽，手机也无法运行九个编码器而不过热。
当SFU介入时，无论参与者数量如何，上传带宽保持恒定。随着可见参与者的数量增加，下载带宽会增长，但通过层流技术，服务器可以发送小缩略图，除了活跃发言者。
MCU在客户端带宽方面胜出，但需要付出高额的服务器CPU成本。
当今大多数生产系统使用SFU，某些系统还会添加MCU样式的混音器，专门用于录制或拨入电话系统。
在WebRTC SFU中，每个客户端将服务器视为一个普通的对等方。以下是加入房间时发生的过程。
步骤5和步骤7是“选择性”发生的部分。服务器不会解码视频，但可以读取足够的元数据，在正确的帧边界上切换质量。
SFU将每个参与者建模为发布者、订阅者或两者。在小组会议中，每个人都既是发布者又是订阅者；而在网络研讨会中，二到三个主持人发布，其他所有人仅订阅。
一些SFU使用一个对等连接方向：一个用于发布，一个用于订阅。其他SFU使用单个对等连接，但具有多个传输器。
这两种方法都可以正常工作。分离的连接使重新协商更简单；单个连接节省了ICE和DTLS握手。