基于node-webrtc(wrtc)如何将入站轨道/流转发给多个对端？

报错根因 #

报错DOMException: Failed to execute 'addTrack' on 'RTCPeerConnection': A sender already exists for the track的本质是WebRTC规范的硬约束：同一个MediaStreamTrack实例在整个node-webrtc/浏览器运行时中，全局仅能绑定到一个RTCRtpSender对象上。
你将从某条入站RTCPeerConnection上收到的原始Track实例，重复调用addTrack添加到多条服务端到参会者的出站连接时，第二条及以后的连接就会因为该Track已经被之前的sender绑定，触发上述报错。这个问题和RTCRtpTransceiver本身的设计逻辑无关，单纯是Track实例的全局绑定规则限制。

核心实现逻辑 #

• 禁止直接复用从对端接收到的原始入站Track实例做转发，每个需要接收该媒体流的出站连接，都要绑定独立的MediaStreamTrack实例
• 服务端作为房间中继节点，针对每一路入站音视频Track，为每个目标参会端单独搭建一条RTP透传链路，从入站Receiver读取RTP包，喂给对应出站Sender的独立Track
• 只要满足“每个RTCRtpSender绑定的Track实例全局唯一”的约束，就不会触发绑定报错，完全兼容标准WebRTC的SDP协商流程

最小可运行实现参考 #

const wrtc = require('wrtc');
// 维护房间内所有参会端的连接映射
const roomPeerMap = new Map();
// 维护入站Track的转发映射：key为入站Track唯一标识，value为对应的接收端和消费列表
const trackForwardMap = new Map();

// 处理每个参会端接入服务端的PeerConnection
function handlePeerConnect(pc, roomId) {
  // 收到对端发上来的Track时触发
  pc.ontrack = (event) => {
    const incomingTrack = event.track;
    const trackKey = `${incomingTrack.id}_${incomingTrack.kind}`;
    const forwardEntry = {
      kind: incomingTrack.kind,
      receiver: event.receiver,
      sourcePeerId: pc.peerId
    };
    trackForwardMap.set(trackKey, forwardEntry);

    // 遍历房间内其他所有参会端，为每个目标端单独创建出站Track
    roomPeerMap.get(roomId).forEach(targetPc => {
      // 跳过源端本身，不向源端转发自己发上来的流
      if (targetPc.peerId === pc.peerId) return;

      // 关键：为每个目标端创建独立的出站Track实例，不复用原始入站Track
      const outboundTrack = wrtc.nonstandard.createTrack(
        incomingTrack.kind,
        // 媒体读取回调：从入站Receiver拉取RTP包喂给出站Track
        () => {
          return forwardEntry.receiver.readRtp();
        }
      );
      // 独立Track实例不存在重复绑定问题，可正常addTrack
      targetPc.addTrack(outboundTrack, new wrtc.MediaStream());
      // 触发协商流程，通过SDP把新的媒体流告知目标端
      targetPc.createOffer().then(offer => targetPc.setLocalDescription(offer));
    });
  };

  // 处理参会端离开的清理逻辑
  pc.onconnectionstatechange = () => {
    if (pc.connectionState === 'closed' || pc.connectionState === 'failed') {
      roomPeerMap.get(roomId)?.delete(pc);
    }
  };
}

关键注意事项 #

• 不要尝试通过手动创建RTCRtpTransceiver、强行把同一个Track挂载到多个Transceiver上解决问题：Transceiver本身和RTCRtpSender是一一绑定的，本质还是绕不开“一个Track对应一个sender”的全局约束
• 你之前提到的按Stream维度管理转发逻辑的思路完全可行：只需要把每个独立的出站Track按所属的入站源Stream分组，绑定到同一个出站MediaStream实例上，就可以实现和已废弃的addStream一致的管理效果，同时兼容标准WebRTC的最新规范
• 入站Track的静音、开关状态可以同步映射给所有对应的出站Track，但不能直接把原始Track实例复用给出站连接
• 该方案是纯RTP层的透传转发，不需要引入额外的媒体转码组件，node-webrtc原生支持从Receiver读取RTP包、往Sender写入RTP包的能力，完全满足低延迟的会议中继需求
• 早期官方多人示例里“本地采集流分发多个对端”的场景能正常工作，本质是因为本地采集的Track本身没有被绑定到其他sender上，和“从入站连接接收Track再跨连接转发”的场景存在本质差异

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