信令服务器

信令服务器在对等端之间转发控制消息，使浏览器可以协商连接。WebRTC 不规定信令协议，常见实现为 WebSocket；HTTP 轮询、SSE 加 HTTP 发送也可以。

信令不转发正常的音视频或数据通道内容；但连接无法直连时，TURN 会转发媒体与数据。

需要交换的消息

消息	作用
offer	发起方提供 SDP 描述
answer	接收方接受后的 SDP 描述
ice-candidate	增量交换可用网络路径
join / leave	房间成员与通话生命周期
hangup / renegotiate	显式结束或重新协商

信令消息的格式由业务定义，但应包含房间或会话 ID、发件人与收件人标识、消息类型与载荷。服务端必须检查用户是否有加入该房间和向目标用户发消息的权限。

典型流程

A 进入房间 ───────> 信令服务 <─────── B 进入房间
A: offer ─────────> 信令服务 ────────> B
B: answer ────────> 信令服务 ────────> A
A/B: ICE candidate ↔ 信令服务 ↔ 对方
A ⇄ B：建立媒体与数据连接（必要时经 TURN）

协商冲突

双方同时创建 offer 会发生 glare。应用应采用“完美协商（perfect negotiation）”模式：约定一端为 polite，收到冲突 offer 时回滚并接受；另一端为 impolite，忽略冲突 offer。不要依赖“谁先点击按钮”来避免冲突。

新增或移除轨道会触发 negotiationneeded。在该事件中创建 offer 并通过信令发送；远端完成 setRemoteDescription()、createAnswer() 与 setLocalDescription() 后回传 answer。

服务端职责

• 认证用户，授权房间访问，并在断连时清理成员状态。
• 只转发必要控制消息，限制消息大小与频率。
• 不持久化敏感 SDP/候选；日志应避免记录令牌和完整网络地址。
• 信令断开后，已建立的 WebRTC 连接未必立即中断；业务仍需定义重连、挂断和成员状态策略。