28、WebRTC与IoT：WebRTC在物联网中的应用、摄像头设备直连、低功耗设备适配、边缘计算场景

聊到WebRTC和IoT的结合，我其实挺有感触的。几年前我接手过一个智能门铃项目，客户要求手机端能实时看到门口画面，还要能双向通话。当时第一反应是用传统的RTMP或者HLS方案，但延迟问题一直搞不定。后来我试着把WebRTC塞进那个只有几百KB内存的摄像头里——嗯，过程确实挺折腾的，但结果出乎意料地好。

说白了，WebRTC在IoT场景下的核心价值就三个字：低延迟。你想想看，智能门铃、无人机图传、工业巡检机器人，哪个能忍受两三秒的延迟？WebRTC的端到端延迟能做到200ms以内，这在IoT领域简直就是降维打击。

摄像头设备直连：从浏览器到嵌入式

传统WebRTC应用，两端都是浏览器或者App。但在IoT场景里，其中一端往往是资源受限的嵌入式设备。比如一个海思3516芯片的摄像头，跑着Linux系统，内存只有128MB。怎么让它直接参与WebRTC通信？

我个人的习惯是，在设备端跑一个轻量级的WebRTC Native实现。目前主流的选择有两个：

• libwebrtc：Google官方库，功能最全，但体积大（编译后约20MB），适合性能较好的设备。
• libdatachannel：纯C++17实现，只支持DataChannel，体积小（约500KB），适合极低功耗场景。

如果你需要音视频传输，那基本只能选libwebrtc。不过别怕，我们可以裁剪。我在项目中做过一个裁剪方案，把不需要的编解码器、传输协议都去掉，最终编译出来的库只有6MB左右。对于大多数IoT设备来说，这个大小是可以接受的。

来看一个简单的设备端代码片段，展示如何初始化WebRTC PeerConnection：

// 设备端（C++）初始化PeerConnection
rtc::scoped_refptr<webrtc::PeerConnectionFactoryInterface> factory;
webrtc::PeerConnectionInterface::RTCConfiguration config;
config.sdp_semantics = webrtc::SdpSemantics::kUnifiedPlan;

// 添加ICE服务器（可以用TURN，但IoT场景建议用P2P）
webrtc::PeerConnectionInterface::IceServer server;
server.uri = "stun:stun.l.google.com:19302";
config.servers.push_back(server);

// 创建PeerConnection
auto pc = factory->CreatePeerConnection(config, nullptr, nullptr, this);

// 添加视频轨道（从摄像头采集）
auto video_track = factory->CreateVideoTrack("video", capture);
pc->AddTrack(video_track, {"stream1"});

// 创建Offer并发送
pc->CreateOffer(this, webrtc::PeerConnectionInterface::RTCOfferAnswerOptions());

这段代码看着简单，但实际部署时坑不少。我曾经在一个项目里发现，设备端创建的Offer里SDP格式不对，导致浏览器端一直报错。排查了半天，原来是libwebrtc版本太旧，生成的SDP里缺少了某些rtpmap字段。所以我的建议是：尽量保持libwebrtc版本与浏览器端一致，至少大版本号要对齐。

低功耗设备适配：让电池撑得更久

IoT设备很多是电池供电的，比如无线门铃、户外传感器。WebRTC默认是为PC和手机设计的，功耗优化做得并不好。你想想看，一个摄像头如果一直保持ICE连接心跳，电池可能撑不过一天。

怎么解决？我总结了几条实战经验：

• 按需建立连接：不要一直保持PeerConnection。设备平时处于休眠状态，有人触发事件（比如按门铃、检测到移动）才唤醒并建立连接。
• 降低视频分辨率：默认720p的编码功耗很高。对于IoT场景，480p甚至360p就够用了。我在项目中把分辨率降到480p后，编码功耗降低了约40%。
• 使用H.264硬件编码：很多IoT芯片（比如海思、安霸）都内置了H.264硬件编码器。用硬件编码代替软件编码，功耗能降低60%以上。
• 调整ICE保活间隔：默认ICE保活是每15秒一次。对于IoT设备，可以放宽到60秒甚至更长。但要注意，NAT映射可能会超时，需要根据实际网络环境测试。

还有一个容易被忽略的点：音频编解码器的选择。Opus编码器虽然音质好，但计算复杂度高。对于只需要语音对讲的IoT设备，我建议用PCMU或者PCMA，解码功耗只有Opus的1/3左右。当然，音质会差一些，但门铃对讲场景完全够用。

边缘计算场景：把WebRTC搬到边缘节点

边缘计算是IoT里一个很火的方向。说白了，就是把计算能力从云端下沉到离设备更近的地方。WebRTC在边缘计算中能做什么？我举两个实际场景：

• 视频分析前置：摄像头采集的视频，先送到边缘节点做AI分析（比如人脸识别、异常检测），再把结果和视频流一起传给用户。这样既降低了云端带宽成本，又减少了端到端延迟。
• 媒体流混流转发：多个IoT设备同时上传视频，边缘节点做SFU（Selective Forwarding Unit），把多路流混成一路或者选择性转发给用户。这样用户端不需要同时处理多路流，减轻了终端压力。

边缘节点上跑WebRTC，我推荐用Janus或者Mediasoup这类开源SFU。它们都支持在Linux服务器上部署，而且对硬件资源要求不高。我在一个树莓派4B上跑过Mediasoup，同时转发4路720p视频流，CPU占用率只有30%左右，效果相当不错。

来看一个边缘节点上配置SFU的示例：

// Mediasoup 边缘节点配置示例
const worker = await mediasoup.createWorker({
  logLevel: 'warn',
  logTags: ['info', 'ice', 'dtls', 'rtp', 'srtp', 'rtcp'],
  rtcMinPort: 40000,
  rtcMaxPort: 49999,
});

const router = await worker.createRouter({
  mediaCodecs: [
    {
      kind: 'video',
      mimeType: 'video/H264',
      clockRate: 90000,
      parameters: {
        'packetization-mode': 1,
        'profile-level-id': '42e01f',
        'level-asymmetry-allowed': 1,
      },
    },
    {
      kind: 'audio',
      mimeType: 'audio/PCMU',
      clockRate: 8000,
      channels: 1,
    },
  ],
});

这里要注意，边缘节点的编解码器配置要和设备端匹配。我遇到过一个问题：设备端用的是H.264 Baseline Profile，但边缘节点配置成了Main Profile，结果视频一直黑屏。排查了半天才发现是profile不匹配。所以我的建议是：在设备端和边缘节点之间，提前约定好编解码器参数，最好在信令阶段就协商清楚。

知识体系总览

下面这张图总结了WebRTC在IoT场景下的核心架构和关键环节：

从这张图可以看出，WebRTC在IoT场景下是一个三层架构：设备端负责采集和编码，边缘节点负责处理和转发，用户终端负责呈现和交互。每一层都有各自的挑战，但核心思路是一致的——在资源受限的环境下，用最小的代价实现实时音视频通信。

好了，关于WebRTC在IoT中的应用，我就分享这么多。如果你在实际项目中遇到什么问题，欢迎随时交流。记住，IoT场景下的WebRTC，核心不是功能多强大，而是恰到好处——够用、省电、稳定，这才是王道。