WebRTC Data Channel已开启但无法发送数据问题求助

核心问题分析 #

你的Data Channel调用send无反应，本质是PeerConnection未完成完整的ICE协商与连接建立，Data Channel实际处于未激活状态——即便本地创建了通道对象，也无法传输数据。以下是具体问题点及修复方案：

1. Data Channel创建逻辑错误 #

• 问题：当前客户端无论作为发起方（创建Offer）还是应答方（创建Answer），都主动调用createDataChannel。但WebRTC规范中，只有发起方可以主动创建通道，应答方必须通过localConnection.ondatachannel事件接收通道，否则双方通道无法匹配。
• 修复：
  • 发起方（收到createOffer指令时）创建Data Channel；
  • 应答方监听ondatachannel事件获取通道。

修改客户端代码：

// 移除全局的dataChannel创建，改为按需创建
let dataChannel = null;

// 在ws.onopen里添加ondatachannel监听
localConnection.ondatachannel = (event) => {
  dataChannel = event.channel;
  setDataChannelListeners(dataChannel);
};

// 封装通道监听函数
function setDataChannelListeners(channel) {
  channel.onmessage = (e) => console.log("messsage received!!!" + e.data);
  channel.onopen = (e) => console.log("open!!!!");
  channel.onclose = (e) => console.log("closed!!!!!!");
}

// 在createOffer的case里创建通道
case "createOffer":
  console.log("Creating Offer!");
  // 发起方创建Data Channel
  dataChannel = localConnection.createDataChannel("sendChannel");
  setDataChannelListeners(dataChannel);
  localConnection.createOffer()
  .then(o => {
       localConnection.setLocalDescription(o);
  });
  break;

2. ICE Candidate未正确交换 #

• 问题：客户端onicecandidate发送的消息类型是"create"+ localConnection.localDescription.type（即createoffer/createanswer），但服务端仅处理了createoffer类型，应答方的ICE Candidate无法被服务端转发给发起方，导致PeerConnection无法完成ICE协商。
• 修复：
  • 客户端单独发送ICE Candidate消息，类型设为"iceCandidate"；
  • 服务端新增iceCandidate处理逻辑，将ICE Candidate转发给对应的对等方。

客户端修改onicecandidate：

localConnection.onicecandidate = (e) => {
  if (!e.candidate) return; // 忽略空的candidate
  console.log("New ICE Candidate!", e.candidate);
  ws.send(JSON.stringify({
    type: "iceCandidate",
    data: {
      id: ID,
      candidate: e.candidate
    }
  }));
};

服务端新增iceCandidate的case：

case "iceCandidate":
  // 找到配对的对等方（需完善配对逻辑，示例为找到已应答的用户）
  for (const [userId, user] of freeUsers) {
    if (userId !== m.data.id && user.ans) {
      user.ws.send(JSON.stringify({
        type: "remoteIceCandidate",
        data: m.data.candidate
      }));
      break;
    }
  }
  break;

客户端新增remoteIceCandidate的case：

case "remoteIceCandidate":
  localConnection.addIceCandidate(new RTCIceCandidate(data.data))
  .catch(err => console.error("Failed to add ICE candidate:", err));
  break;

3. ID赋值错误 #

• 问题：在newclient的case中，你已经通过data = JSON.parse(event.data)解析了数据，却又重复执行JSON.parse(event.data).id，会导致解析错误，最终ID为null，后续发送ICE Candidate时服务端无法识别用户。
• 修复：

case "newclient":
  console.log("New client id", data.id);
  ID = data.id;
  break;

4. 服务端SDP类型不匹配 #

• 问题：客户端发送Answer的类型是"answer"，但服务端的处理case是"createanswer"，类型不匹配，导致服务端无法转发Answer给发起方，PeerConnection无法完成连接。
• 修复：
  服务端修改case：

case "answer":
  const freeUser = freeUsers.get(m.data.sessionid);
  if (freeUser) {
    freeUser.ws.send(JSON.stringify({ 
      type: "acceptAnswer", 
      message: "Answer from client", 
      data: m.data 
    }));
    freeUser.ans = true;
  }
  break;

5. 服务端配对逻辑不完善 #

• 问题：当前服务端用freeUsers.entries().next().value获取第一个空闲用户，但没有维护用户间的配对关系，导致后续ICE Candidate无法正确转发。建议在用户配对后从freeUsers移除，避免重复匹配。

验证步骤 #

1. 启动服务端，打开两个客户端页面；
2. 第一个客户端会收到createOffer指令，创建Offer并发送给服务端；
3. 第二个客户端会收到createAnswer指令，设置远程SDP并发送Answer；
4. 观察控制台是否打印open!!!!，表示Data Channel已激活；
5. 点击发送按钮，查看对方控制台是否收到消息。

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