webman不能处理webrtc媒体流，仅可作为信令与业务中枢；它负责jwt鉴权、房间管理、websocket信令透传、联动sfu创建房间及qos数据聚合，所有音视频流必须直连媒体服务器udp端口，不可经webman转发。
Webman 在 WebRTC 架构里到底该干什么
它不是媒体服务器，也不是 SDP 协商引擎，它的合理角色是「轻量、可靠、可审计的胶水层」：
- 用户登录鉴权：校验 JWT 或对接企业 LDAP/AD，拒绝非法接入
- 房间生命周期管理：创建/销毁房间时写入 Redis，踢人操作广播到 WebSocket 群组
- 信令透传：收到
offer、answer、ice-candidate后不做解析、不改内容，原样转发给目标客户端 - 联动媒体服务器：调用
curl -X POST http://mediasoup:3004/v1/rooms创建 SFU 房间，拿到返回的roomId和token再推给前端 - QoS 数据聚合：从客户端上报的
getStats()JSON 中提取inbound-rtp.packetsLost、jitter，存入 MySQL 表meeting_qos_log
为什么不能用 Webman 直接转发音视频流
这不是性能优化问题，而是能力缺失问题。Webman（哪怕 2.2.0 版本）仍不具备以下 WebRTC 媒体面必需能力：
Webman 2.2.0
下载
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 无
RTCPeerConnection实现，无法解析 DTLS-SRTP 握手包或 SRTP 密钥派生 - 不支持 UDP 流式接收/发送，而 WebRTC 媒体面强制走 UDP；Swoole 的
udp_server仅用于监控或简单协议，无法承载 RTP/RTCP 包的乱序重排、NACK 处理、PLI 请求响应 - 没有硬件加速接口（如 VA-API/NVENC），无法做实时转码或分辨率适配
- 缺乏 ICE 候选者状态机，无法处理
candidate的 trickle 交换、连通性检查（connectivity check）或失败回退逻辑 - 强行在 PHP 层模拟这些，会导致信令延迟飙升、ICE 连接成功率低于 40%、多人会议中频繁断连
Webman + WebRTC 的最小可行协作流程
以用户点击“加入会议”为例，真实链路如下：
- 前端发
POST /api/join?room_id=abc123&user_id=u456到 Webman - Webman 校验 JWT，查 Redis 确认房间存在且未满员，然后调用
http://mediasoup:3004/v1/rooms/abc123/join，传入{ "name": "u456", "audio": true, "video": true } - Mediasoup 返回
{ "peerId": "p789", "rtpCapabilities": {...}, "sctpCapabilities": {...} }，Webman 提取rtpCapabilities并拼进自己的响应体，同时将peerId存入redis:hset meeting:abc123:peers u456 p789 - 前端拿到响应后，用
rtpCapabilities初始化mediasoup-client的Device，再调用device.createSendTransport(...)建立传输通道 - 所有后续的
transport.produce()、transport.consume()都直连 Mediasoup，Webman 不参与
webrtcTransport.listenIp.ip 配置项）。一旦把媒体流引到 Webman 的 TCP 接口，整个链路就废了。
