关于ApiRTC中meshModeEnabled与meshOnlyEnabled设为true的行为问询

核心流量路由行为 #

• 当meshModeEnabled和meshOnlyEnabled同时设为true时，ApiRTC会强制锁定纯P2P网格传输模式，彻底禁用SFU的流量中转能力。所有音频、视频、屏幕共享流都直接在终端设备间点对点传输，完全不经过Apizee的SFU服务器。
• 哪怕会话参与人数超过P2P模式的常规适配上限（比如4人及以上），系统也不会触发自动切换SFU的逻辑，始终维持P2P连接拓扑。

会话录制与媒体检索的限制 #

• 由于会话录制和API媒体检索功能的核心依赖是SFU对媒体流的统一捕获、转码和存储，在纯P2P模式下（无SFU介入），这两个功能完全无法使用：
  • 发起录制请求会被系统直接驳回，无法启动录制任务；
  • 事后调用媒体检索API时，会返回空结果或错误响应，因为没有SFU留存对应的媒体数据。

其他技术细节 #

• 媒体质量调整仅依赖终端间的点对点带宽，没有SFU侧的码率适配或转码处理；
• 无法通过Apizee PaaS后台API获取会话全局媒体统计数据（如整体丢包率、延迟），只能从本地终端获取单节点统计；
• 所有依赖SFU的高级功能（比如多画面布局管控、媒体流混音）都会失效。

内容的提问来源于stack exchange，提问作者Tang J