WebRTC视频中继问题：Node.js基站无法触发远端站onTrack事件

核心问题根源 #

1. Node.js 原生无浏览器级别的 MediaStream/MediaStreamTrack 实现，必须依赖兼容库（如 wrtc）提供的对应对象
2. 中继轨道时未触发信令重新协商：已建立的 PeerConnection 新增轨道后，需重新生成 SDP 并交换，远端站才能感知到新轨道
3. 代码中存在轨道/流存储的逻辑错误，且信令时机判断不严谨

具体解决方案 #

1. 依赖库选型与初始化

必须使用 wrtc 作为 Node.js 环境的 WebRTC 实现，确保所有 WebRTC 相关对象均来自该库：

npm install wrtc

代码中导入对应对象：

const { RTCPeerConnection, MediaStream } = require('wrtc');

// 初始化两个 PeerConnection，需配置 ICE 服务器
const vehiclePc = new RTCPeerConnection({ iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] });
const remotePc = new RTCPeerConnection({ iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] });

2. 修正轨道中继逻辑

核心是新增轨道后必须触发信令重新协商，同时修正流存储错误：

let incomingTrack = null;
let relayStream = null;

// 处理车辆端传入的轨道
vehiclePc.ontrack = (event) => {
    console.log("--------------------RECEIVED TRACK--------------------");
    incomingTrack = event.track;

    // 初始化中继流（使用 wrtc 的 MediaStream）
    if (!relayStream) {
        relayStream = new MediaStream();
    }
    relayStream.addTrack(incomingTrack);

    // 信令完成判断：需同时存在本地和远端描述
    if (remotePc.localDescription && remotePc.remoteDescription) {
        addTrackAndRenegotiate();
    } else {
        console.log('等待远端站信令完成后中继轨道');
    }
};

// 新增轨道并触发重新协商
async function addTrackAndRenegotiate() {
    try {
        // 先移除旧轨道避免重复
        remotePc.getSenders().forEach(sender => {
            if (sender.track) remotePc.removeTrack(sender);
        });

        // 添加中继轨道
        remotePc.addTrack(incomingTrack, relayStream);

        // 生成新 Offer 并发送给远端站
        const offer = await remotePc.createOffer();
        await remotePc.setLocalDescription(offer);
        // 此处需通过信令服务器将 offer 发送给远端站
        // sendOfferToRemoteStation(offer);
    } catch (err) {
        console.error('中继轨道协商失败:', err);
    }
}

// 处理远端站的 Answer（信令回调示例）
async function handleRemoteAnswer(answer) {
    await remotePc.setRemoteDescription(answer);
    // 若此时已收到车辆轨道，直接触发中继
    if (incomingTrack) {
        await addTrackAndRenegotiate();
    }
}

3. 关键技术建议

• 严格统一 WebRTC 对象来源：所有 RTCPeerConnection、MediaStream、MediaStreamTrack 必须来自 wrtc，禁止混用浏览器 API
• 信令流程严谨性：确保两个 PeerConnection（车辆-基站、基站-远端站）的 Offer/Answer 交换完全完成，ICE 候选收集完毕后再进行轨道中继
• 复杂场景选型：若涉及多车辆/多远端站的中继，建议使用 mediasoup 替代基础 wrtc，它提供更专业的媒体路由、转码和会话管理能力
• 错误排查：可通过打印 SDP 内容确认轨道是否被正确包含，同时检查 ICE 连接状态（remotePc.iceConnectionState）确保链路连通

内容的提问来源于stack exchange，提问作者girlcode