[C/C++] 深入解析RTCPilot信令流程：WebRTC开源SFU核心机制剖析

RTC Pilot 是一个基于 C++17 开发的 WebRTC SFU 开源项目，它支持跨平台运行，涵盖 Windows、Linux 和 macOS，二次开发效率高。值得一提的是，它是目前开源领域中少数全面支持 WebRTC 级联的服务之一。

在之前的分享中，我们介绍了如何搭建 RTC Pilot 集群以构建分布式视频会议系统。本文将聚焦于 RTCPilot 的信令流程，旨在帮助开发者深入理解其内部通信机制，从而更高效地进行二次开发。

信令基础：消息类型

RTCPilot 的信令基于 WebSocket 协议，主要分为两类消息：

• Request 消息：这类消息包含请求与响应（Response），是双向通信。
• Notify 消息：这类消息仅用于单向通知，发送后没有回复。

上图清晰地展示了涉及三个角色（Client A, Client B 及 RTCPilot SFU）的完整信令交互过程，是理解后续步骤的关键。

信令流程逐步解析

让我们结合流程图，详细拆解两个客户端通过 SFU 建立通信的每一步：

1. Join Request：Client A 在 WebSocket 连接建立成功后，首先发送 join request 消息加入房间。由于此时房间内没有其他用户，SFU 返回的响应中用户列表为空。
2. Push Request：Client A 加入房间后，随即发送 push request 消息，将自己的 WebRTC Peer Connection 的 SDP（Session Description Protocol）描述告知 SFU。SFU 处理后会通过 response 消息返回其自身支持的 SDP 信息。Client A 收到后，便可开始建立 WebRTC 传输通道并进行推流。
3. Client B 加入：随后，Client B 连接 SFU 并发送 join request 消息。由于房间内已存在 Client A，SFU 会在给 Client B 的 response 中附带 Client A 的用户信息及流信息。
4. 广播新用户：SFU 在收到 Client B 的 join request 后，会向房间内所有现有用户广播新成员加入的事件。此处，它会向 Client A 发送一个 newUser notify 消息。
5. Client B 拉流：Client B 通过步骤3的 join response 获知了 Client A 的推流信息，因此可以主动发送 pull request 消息，向 SFU 请求拉取 Client A 的媒体流。
6. Client B 推流：同样地，Client B 在拉流成功后，也可以发起自己的推流，通过发送 push request 消息将它的流发布到 SFU。
7. 广播新流：SFU 收到 Client B 的 push request 后，会将其流信息在房间内进行广播。这里，它会向 Client A 发送一个 newPusher notify 消息。
8. Client A 拉流：最后，Client A 在收到关于 Client B 的 newPusher notify 消息后，便获得了 Client B 的流信息，随即可以发送 pull request 消息来拉取 Client B 的流。

至此，一个完整的双向音视频通信信令流程便建立完毕。

信令报文格式参考

如果你想了解具体信令的 JSON 数据结构与字段定义，可以参考项目仓库中的详细设计文档：

• WebSocket 信令设计文档（GitHub）：https://github.com/runner365/RTCPilot/blob/master/ws_design.md
• 国内镜像（Gitee）：https://gitee.com/xiaoq_bj/rtcpilot/blob/master/ws_design.md

通过剖析 RTCPilot 的信令交互，我们不仅能够理解一个 SFU 架构如何协调客户端之间的连接，也能为基于此类优秀 开源项目 进行定制化开发打下坚实基础。RTCPilot 采用 C++17 开发，其清晰的模块化设计为深入研究 WebRTC 服务端实现提供了很好的范本。希望这篇解析能对你的开发工作有所帮助。