如何选择服务端 WebRTC 实现
内容提要
服务端WebRTC需自选实现库，选型取决于工作负载接触媒体的层次：SFU仅转发已编码RTP，适合Pion（Go）或webrtc-rs（Rust）；AI语音与视觉管线需解码帧，适合aiortc（Python）；媒体管线与硬件加速场景适合GStreamer webrtcbin；IoT与数据通道可用libdatachannel。应优先考虑托管平台或现成媒体服务器，需求超出后再按媒体层次选库。
延伸解读
先分清“实现”与“媒体服务器”
文章强调，WebRTC 实现是协议栈（ICE、DTLS-SRTP、SCTP、RTP/RTCP），而媒体服务器是使用该实现来路由媒体的应用。选型前应先判断项目是否真的需要下探到实现层：语音 AI、SFU、电话网关等大多已有托管平台或开源媒体服务器可用。只有当成本、数据驻留、自定义媒体处理等需求超出高层方案时，才需要自己选库。
媒体层次决定选型方向
文章认为，最具预测力的问题是工作负载在哪一层接触媒体。SFU 只需转发已编码 RTP，适合 Pion 或 webrtc-rs；AI 语音与视觉管线需要解码后的帧，适合 aiortc；媒体管线与硬件加速场景适合 GStreamer webrtcbin；IoT 与数据通道场景可用 libdatachannel。选型应围绕这一层次展开，而非只看语言或成熟度。
换库代价高，演示难暴露局限
文章提醒，库的局限很少在两个对端的演示中暴露，往往在路由、录制和扩容都依赖它之后才显现，届时绕开限制通常意味着重写。因此选型应尽早确认媒体层次，并考虑团队语言与运维习惯、技能储备，以及成熟栈与快速演进新栈之间的差距。
Q&A
服务端 WebRTC 实现和媒体服务器有什么区别？
WebRTC 实现是协议栈（包括 ICE、DTLS-SRTP、SCTP、RTP/RTCP），让进程作为对端参与连接；媒体服务器（如 SFU 或 MCU）是使用某个 WebRTC 实现来在多个对端之间路由媒体的服务端应用。可以类比为发动机零件与整车的关系。
什么时候需要自己选择服务端 WebRTC 库，而不是直接用托管方案？
几乎所有服务端工作负载都有更高层的现成或托管方案（如语音 AI 的 Pipecat、LiveKit Agents，SFU 的 LiveKit、mediasoup、Janus，电话网关的 SIP 插件）。只有当需求超出这些方案时，比如成本、数据驻留、延迟控制、自定义媒体处理、媒体来源非采集设备、非常规部署拓扑或合规控制，才需要下探到实现层，自己选择库。
Pion、aiortc、webrtc-rs 和 GStreamer webrtcbin 各自适合什么场景？
Pion（Go）适合需要原始 RTP 转发的 SFU 和群组媒体，纯 Go 无 C 依赖，部署简单；aiortc（Python）适合 AI 语音/视频代理等需要解码帧的场景，与 ML 管线集成方便；webrtc-rs（Rust）适合追求性能与内存安全的新项目，模块化且 Sans-IO；GStreamer webrtcbin 适合媒体管线与硬件加速场景，以 GStreamer 元素图方式集成。
为什么说选择 WebRTC 实现主要取决于媒体处理层次？
因为不同工作负载在媒体处理的两个层次上操作：已编码的 RTP 包（如 SFU 仅转发）或已解码的帧（如 AI 管线需要处理原始帧）。库能否干净地暴露所需层次，比语言或成熟度更能预测开发工期。例如 SFU 需要原始 RTP 转发，而 AI 代理需要解码后的 PCM 或视频帧。
对于 AI 语音代理或计算机视觉管线，应该选用哪个 WebRTC 库？
推荐 aiortc（Python），因为它直接提供解码后的帧（如 VideoFrame 或 AudioFrame），可以方便地接入机器学习模型或 CV 管线。如果团队更熟悉 Go 或 Rust，Pion 和 webrtc-rs 也同时暴露已编码 RTP 和已解码样本，同样可用。
GStreamer webrtcbin 与其他库在集成方式上有什么不同？
Pion、aiortc、webrtc-rs 是主动调用的库，你持有 peer-connection 对象并用控制流驱动；而 webrtcbin 是 GStreamer 媒体管线中的一个元素，你搭建元素图并响应协商信号，让框架掌握数据流。它适合媒体管线（采集、变换、编码，尤其是硬件加速）场景，但依赖较重。
对于 IoT 或数据通道为主的项目，推荐哪个 WebRTC 实现？
推荐 libdatachannel 或 webrtc-rs。libdatachannel 是轻量 C/C++ 协议栈，适合资源受限硬件；webrtc-rs 也适合低延迟视频下行和控制走数据通道的机器人远程操作等场景。
