📚 课程目录第2章 WebRTC信令机制与嵌入式适配

2、WebRTC信令机制与嵌入式适配：信令协议选型、服务器搭建与交互流程

信令，说白了就是通话双方在建立连接前的那套“握手”流程。谁先说话？用什么格式？加密不加密？这些都得提前商量好。WebRTC 虽然把媒体传输的脏活累活都干了，但信令这块它故意留了个口子——让你自己选。为什么？因为不同场景需求差太多了。

我刚开始做嵌入式 WebRTC 时，觉得信令不就是发几个 JSON 嘛，随便搞搞就行。结果第一次联调，设备端和服务器的信令格式对不上，折腾了两天才发现是 SDP 协商顺序错了。嗯，从那以后我再也不敢小看信令设计了。

2.1 信令协议选型：WebSocket vs SIP

嵌入式环境资源有限，选信令协议不能只看功能，还得看 footprint、功耗、实时性。目前主流就两条路：WebSocket 和 SIP。我列个对比表，你一看就明白。

对比维度	WebSocket	SIP
协议复杂度	低，基于 HTTP 升级，二进制/文本帧	高，完整的 VoIP 信令协议栈
嵌入式适配难度	低，轻量级库（如 libwebsockets）即可	高，需要移植 osip/exosip 等库
与 WebRTC 原生集成	天然适配，JS 原生支持	需要 SIP-SDP 映射，额外封装
NAT 穿透	依赖上层 STUN/TURN	自带 ICE 集成，但复杂
典型场景	浏览器-设备直连、IoT 监控	运营商级 VoIP、SIP 话机
内存占用（参考）	~50KB（libwebsockets）	~200KB（osip + exosip）

我的建议：如果你做的是纯嵌入式设备（摄像头、门铃、机器人），选 WebSocket。它轻、快、好调试。如果你需要对接现有 SIP 电话网络（比如企业通信系统），那就硬着头皮上 SIP，但要做好移植和裁剪的准备。

2.2 信令服务器搭建：轻量级方案

服务器端我习惯用 Node.js + ws 库，几分钟就能跑起来。为什么不用 Java 或 C++？嵌入式调试阶段，快速验证比性能更重要。等原型通了，再考虑用 C++ 重写高性能信令网关。

下面是一个最小可用的信令服务器核心代码，处理房间管理和消息转发：

const WebSocket = require('ws');
const server = new WebSocket.Server({ port: 8080 });
const rooms = new Map(); // roomId -> Set<ws>

server.on('connection', (ws) => {
  let currentRoom = null;

  ws.on('message', (msg) => {
    const data = JSON.parse(msg);
    switch (data.type) {
      case 'join':
        currentRoom = data.room;
        if (!rooms.has(currentRoom)) rooms.set(currentRoom, new Set());
        rooms.get(currentRoom).add(ws);
        // 通知房间内其他用户
        broadcast(currentRoom, { type: 'user-joined', id: data.id }, ws);
        break;
      case 'offer':
      case 'answer':
      case 'ice-candidate':
        // 转发给房间内指定用户
        forwardTo(currentRoom, data.target, data);
        break;
      case 'leave':
        rooms.get(currentRoom)?.delete(ws);
        broadcast(currentRoom, { type: 'user-left', id: data.id });
        break;
    }
  });

  ws.on('close', () => {
    rooms.get(currentRoom)?.delete(ws);
  });
});

避坑指南：我曾经在生产环境遇到过 WebSocket 连接数暴涨导致 OOM 的问题。原因很简单——没有做心跳检测。嵌入式设备网络不稳定，断连后服务端没及时清理僵尸连接。务必加上 ping/pong 机制，超时 30 秒未响应就主动断开。

2.3 嵌入式端信令交互流程

嵌入式端（比如基于 Linux + libwebsockets 的摄像头）的信令流程，说白了就是“连接-加入房间-交换 SDP/ICE-通话-离开”。但细节里全是坑。我画了一张流程图，把关键步骤和状态都标出来了。

2.4 嵌入式端代码实现要点

嵌入式端用 C 语言实现信令交互，核心是事件驱动。我以 libwebsockets 为例，展示关键的数据结构设计和消息处理逻辑。

2.4.1 信令消息结构体

typedef enum {
    MSG_JOIN,
    MSG_OFFER,
    MSG_ANSWER,
    MSG_ICE_CANDIDATE,
    MSG_LEAVE,
    MSG_HEARTBEAT
} signal_msg_type_t;

typedef struct {
    signal_msg_type_t type;
    char room_id[32];
    char sender_id[32];
    char target_id[32];
    char payload[2048];  // SDP 或 ICE 内容
} signal_message_t;

2.4.2 消息接收与分发

static int callback_websocket(struct lws *wsi, enum lws_callback_reasons reason,
                              void *user, void *in, size_t len) {
    switch (reason) {
        case LWS_CALLBACK_CLIENT_ESTABLISHED:
            // 连接成功，发送 join
            send_join_message(wsi, "room_001", "device_001");
            break;

        case LWS_CALLBACK_CLIENT_RECEIVE:
            // 解析 JSON 并分发
            signal_message_t msg;
            parse_signal_message((char *)in, len, &msg);
            handle_signal_message(wsi, &msg);
            break;

        case LWS_CALLBACK_CLIENT_CLOSED:
            // 断线重连逻辑
            schedule_reconnect();
            break;

        default:
            break;
    }
    return 0;
}

static void handle_signal_message(struct lws *wsi, signal_message_t *msg) {
    switch (msg->type) {
        case MSG_OFFER:
            // 设置远端 SDP，生成 Answer
            peer_connection_set_remote_sdp(msg->payload);
            peer_connection_create_answer();
            break;
        case MSG_ICE_CANDIDATE:
            // 添加 ICE 候选
            peer_connection_add_ice_candidate(msg->payload);
            break;
        // ... 其他类型处理
    }
}

注意：嵌入式设备内存有限，SDP 字符串可能长达 4KB 以上。我见过有人用栈上固定数组接收，结果 SDP 一长就栈溢出。建议用动态分配或环形缓冲区，并且做长度校验。另外，JSON 解析库别用那种全功能版的，太胖。我习惯用 cJSON，裁剪后不到 20KB。

2.5 信令交互的常见故障与定位

信令出问题，通话根本建不起来。我总结了几类高频故障，你调试时可以直接对照。

故障现象	可能原因	排查方法
WebSocket 连接失败	端口不通 / 协议版本不匹配	抓包看 HTTP Upgrade 响应
join 后无响应	房间 ID 不匹配 / 服务端未广播	服务端日志打印房间成员列表
Offer 发送后收不到 Answer	SDP 格式错误 / 对端未创建 PeerConnection	校验 SDP 的 m= 行和 a= 属性
ICE 候选交换完成但媒体不通	NAT 穿透失败 / TURN 未配置	检查 ICE 状态机，看是否进入 connected
通话中途断开	心跳超时 / 网络闪断	增加重连机制，指数退避

我的调试习惯：在嵌入式设备上开一个 debug 串口，把信令消息的原始 JSON 打印出来。同时服务端也打印一份。两边一对比，问题在哪一目了然。我曾经靠这个办法，半小时就定位到一个 SDP 中缺少 a=ice-ufrag 字段的 bug——那家伙藏得真深。

2.6 信令安全与嵌入式适配

信令通道如果不加密，SDP 里的 IP 和端口就裸奔了。嵌入式设备性能弱，但也不能省这一步。我建议：

WebSocket 必须走 WSS（即 TLS over WebSocket）。libwebsockets 支持 mbedTLS，内存占用增加约 30KB，可以接受。
信令消息加 token 鉴权。每个 join 消息携带设备 ID + 时间戳 + HMAC 签名，服务端验证。防止恶意设备乱入。
心跳带序列号。防止重放攻击。序列号单调递增，服务端记录每个设备的最新序列号。

说白了，信令就是通话的“交通指挥”。指挥错了，车就跑偏。嵌入式环境里，资源受限、网络不稳定，信令设计更要讲究“稳”和“省”。稳，是指状态机清晰、超时重试完备；省，是指协议轻量、内存可控。这两点做到了，你的嵌入式 WebRTC 通话就成功了一半。