webman 不可用于处理 webrtc 媒体流，因其缺乏 rtcpeerconnection、udp 流支持、dtls-srtp 解析等能力；它仅应作为信令与业务中枢，负责鉴权、房间管理、websocket 透传及媒体服务器联动。
Webman 本身不是 WebRTC 框架，也不直接处理音视频流——它是一个基于 Swoole 的高性能 PHP HTTP 应用框架，常用于构建信令服务、房间管理、用户状态同步等后端逻辑。真正承担低延迟音视频传输的是 WebRTC 客户端（浏览器/APP）与媒体服务器（如 sfu 或 webrtc-streamer）之间的协作。所以，「用 Webman + WebRTC」的实质是：用 Webman 做信令和业务中枢，把 WebRTC 的媒体链路交给更专业的组件跑。
如果你试图让 Webman 直接转发或编解码音视频流，会立刻撞上 PHP 的 I/O 模型瓶颈和无原生 WebRTC API 支持的硬伤——这根本不可行，也违背 WebRTC 设计哲学。
为什么不能用 Webman 处理 WebRTC 媒体流
Webman 运行在 PHP+Swoole 上，其事件循环适合处理高并发 HTTP/WebSocket 请求，但不具备：
- 实时音视频帧级处理能力（无
RTCPeerConnection、无 SRTP 解包/重封装） - UDP 流式传输支持（WebRTC 媒体面必须走 UDP，而
Webman默认只暴露 TCP 接口） - 硬件加速接口（如 VA-API/NVENC），无法替代
sfu类服务做转码/分层/丢包补偿 - 对 DTLS-SRTP 握手、ICE 候选者交换、REMB/Transport-CC 等 WebRTC 底层协议的解析能力
强行在 Webman 中“模拟”这些，只会导致延迟飙升、丢包率上升、连接失败率翻倍——尤其在 3 人以上会议中几乎必然崩溃。
Webman 在 WebRTC 架构中该负责什么
它的合理定位是「轻量、可靠、可审计的信令与业务胶水层」，具体包括：
- 用户登录鉴权（JWT 校验、企业 AD/LDAP 集成）
- 房间生命周期管理（创建/销毁/踢人/静音状态同步）
- WebSocket 信令通道（收发
offer/answer/candidate，不做修改，仅透传） - 与媒体服务器联动（例如调用
webrtc-streamer的 REST API 启动流，或向Janus提交 join 请求） - 日志埋点与 QoS 数据聚合（如从客户端上报的
getStats()中提取丢包率、jitter，存入 Redis 或 MySQL）
示例：当用户点击“加入会议”，Webman 收到请求后，不自己生成 SDP，而是调用 curl -X POST http://webrtc-sfu:8080/v1/rooms/{room_id}/join，拿到 SFU 返回的 offer，再通过 WebSocket 推给前端。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
如何对接 webrtc-streamer 或 SFU（如 mediasoup）
关键不是写多少 PHP 代码，而是明确边界、避免越界。推荐组合：
-
信令层：
Webman+ WebSocket（webman/plugin-websocket插件） -
媒体层：独立部署
mpromonet/webrtc-streamer（适合单流广播/监控类） 或mediasoup（适合多人互动会议） -
网络穿透：为媒体层单独配置 STUN/TURN（
webrtc-streamer --stun-server=stun.l.google.com:19302），Webman不参与
注意一个易错点：Webman 的 WebSocket Server 默认不开启二进制支持，而部分 SFU 的信令要求 binary type。需显式设置：$ws->set(['open_websocket_protocol' => true, 'websocket_subprotocol' => '']);，否则 candidate 传输可能被截断。
前端必须绕开 Webman 做媒体协商
所有 WebRTC 核心操作必须在浏览器中完成，Webman 只负责中转字符串。常见错误写法：
❌ 错误：试图在 PHP 里 new RTCPeerConnection() ❌ 错误：用 file_get_contents() 请求 offer 再 echo 给前端（破坏 ICE 生命周期） ✅ 正确：前端调用 navigator.mediaDevices.getUserMedia() → 创建 RTCPeerConnection → 生成 offer → 通过 Webman WebSocket 发送给对端
特别提醒：Chrome 124+ 对 getUserMedia 的权限策略收紧，若页面非 https 或未在用户手势（click/tap）后触发，会直接拒绝。这个限制和 Webman 无关，但很多开发者误以为是后端没配好。
真正的难点从来不在信令通不通，而在于媒体流能否在弱网下自适应存活——这取决于你选的 SFU 是否支持 SVC、是否启用 NACK/PLI 重传、是否做了带宽估算平滑。这些，Webman 一概不该碰，也碰不了。
