一、理解 RTCPeerConnection 的核心

在 WebRTC 的世界里，RTCPeerConnection 是建立音视频或数据通信的基石。你可以把它想象成在两个浏览器之间搭建一座专属的、安全的数字桥梁。这座桥梁的建立过程，我们称之为“信令交换”和“ICE协商”。简单来说，就是双方需要互相告知“我的地址是什么”、“我支持哪些通信协议”，并最终找到一条可以相互连通的路径。当连接建立失败时，问题往往就出在这几个关键环节：信令交换出错、网络地址（ICE候选）收集或交换失败、安全证书（DTLS/SRTP）协商不通过，或者是对端状态异常。

二、连接失败常见原因深度剖析

2.1 信令交换失败或错误

信令通道（通常使用 WebSocket 或 Socket.IO）负责在两端交换 offer、answer 和 ICE candidate 这些建桥的“蓝图”。如果这个通道本身出了问题，或者交换的数据格式不对，桥就无从建起。

示例1：信令交换逻辑错误

// 技术栈：JavaScript (WebRTC API) + WebSocket
// 错误示例：本地和远程描述设置顺序混乱
let pc = new RTCPeerConnection();
let ws = new WebSocket('wss://yoursignaling.server');

// 错误：在收到answer之前就添加了track，并立即创建了offer
navigator.mediaDevices.getUserMedia({video: true})
  .then(stream => {
    stream.getTracks().forEach(track => pc.addTrack(track, stream));
    // 过早创建offer
    return pc.createOffer();
  })
  .then(offer => {
    // 设置本地描述
    return pc.setLocalDescription(offer);
  })
  .then(() => {
    // 通过信令发送offer
    ws.send(JSON.stringify({type: 'offer', sdp: pc.localDescription.sdp}));
  })
  .catch(e => console.error('创建offer失败:', e));

// 接收answer的逻辑
ws.onmessage = async (event) => {
  const message = JSON.parse(event.data);
  if (message.type === 'answer') {
    // 错误：在设置远程描述(answer)前，可能已经触发了ICE candidate收集，
    // 导致candidate发送给对端时，对端可能还未准备好接收。
    const answer = new RTCSessionDescription({ type: 'answer', sdp: message.sdp });
    try {
      await pc.setRemoteDescription(answer); // 正确应在此之后处理candidate
    } catch (e) {
      console.error('设置远程描述失败:', e);
    }
  } else if (message.type === 'candidate') {
    // 危险：如果answer还没设置，此时添加candidate可能会失败
    try {
      await pc.addIceCandidate(new RTCIceCandidate(message.candidate));
    } catch (e) {
      console.error('添加ICE candidate失败:', e);
    }
  }
};

问题分析：正确的顺序应该是 A 端创建 offer 并 setLocalDescription -> 发送给 B 端 -> B 端 setRemoteDescription(offer) -> B 端创建 answer 并 setLocalDescription -> 发送给 A 端 -> A 端 setRemoteDescription(answer)。ICE candidate 的交换应在 setRemoteDescription 之后进行，以确保两端有统一的基础“会话上下文”（SDP）。

2.2 ICE 候选地址收集与连通性失败

这是最常见的问题所在。ICE 框架的任务是找到两端都能访问的 IP 地址和端口。它依次尝试三种类型的候选地址：

  1. 主机候选：设备自身的本地 IP。
  2. 反射候选：通过 STUN 服务器获取的、经过 NAT 映射后的公网 IP 和端口。
  3. 中继候选：当直接连接（P2P）失败时，通过 TURN 服务器中转数据。

如果 STUN 服务器无法访问或配置错误，则无法获得公网地址，在复杂 NAT（如对称型 NAT）后可能无法直连。如果 TURN 服务器配置错误或未配置，则在必须中转时连接会彻底失败。

示例2：ICE 配置与 candidate 收集监听

// 技术栈：JavaScript (WebRTC API)
// 正确的ICE服务器配置与监听
const iceServers = {
  iceServers: [
    { urls: 'stun:stun.l.google.com:19302' }, // 公共STUN服务器
    { 
      urls: 'turn:yourturn.server.com:3478', // TURN服务器地址
      username: 'your_username', // 认证信息
      credential: 'your_credential'
    }
  ]
};

let pc = new RTCPeerConnection(iceServers);

// 监听ICE candidate生成事件，这是收集“建桥地址”的关键
pc.onicecandidate = (event) => {
  if (event.candidate) {
    // 将candidate通过信令发送给对端
    console.log('发现本地ICE candidate:', event.candidate.candidate);
    signalingChannel.send({
      type: 'candidate',
      candidate: event.candidate
    });
  } else {
    // event.candidate为null，表示ICE candidate收集完成
    console.log('ICE candidate收集结束');
  }
};

// 监听ICE连接状态变化
pc.oniceconnectionstatechange = () => {
  console.log('ICE连接状态:', pc.iceConnectionState);
  // 状态可能为：new, checking, connected, completed, failed, disconnected, closed
  if (pc.iceConnectionState === 'failed') {
    // 触发此状态，表明所有候选地址对尝试连通均失败
    console.error('ICE连接失败，可能原因：网络不通、防火墙/NAT限制过严、TURN服务器未配置或不可用。');
    // 通常需要尝试重启ICE或提示用户检查网络
  }
  if (pc.iceConnectionState === 'disconnected') {
    // 连接已建立但暂时中断，可能网络波动
    console.warn('ICE连接断开');
  }
};

2.3 SDP 不兼容与媒体协商问题

会话描述协议（SDP）包含了媒体类型、编解码器、端口等信息。如果两端没有共同的编解码器支持，或者 SDP 在修改过程中出现语法错误，连接也会失败。

示例3：处理编解码器与 SDP 修改

// 技术栈：JavaScript (WebRTC API)
// 创建PeerConnection时指定更偏好VP8编解码器（示例性修改，实际支持度有限）
let pc = new RTCPeerConnection();

// 方法1：在createOffer时使用offerOptions（更推荐）
pc.createOffer({
  offerToReceiveAudio: 1,
  offerToReceiveVideo: 1
}).then(offer => {
  // 方法2：通过正则简单修改SDP（需谨慎，可能破坏SDP）
  // 例如，将H264的优先级调低（这只是一个演示，生产环境应用m-line操作或transceiver API）
  // offer.sdp = offer.sdp.replace('a=rtpmap:127 H264/90000', 'a=rtpmap:127 H264/90000\r\nb=AS:500'); // 限制带宽示例
  return pc.setLocalDescription(offer);
});

// 更现代和可控的方法是使用 transceiver 的 setCodecPreferences
pc.getTransceivers().forEach(transceiver => {
  if (transceiver.receiver.track.kind === 'video') {
    const preferredCodec = RTCRtpSender.getCapabilities('video').codecs.find(codec => codec.mimeType.includes('VP8'));
    if (preferredCodec) {
      transceiver.setCodecPreferences([preferredCodec]);
    }
  }
});

2.4 安全传输（DTLS/SRTP）建立失败

WebRTC 强制使用加密。DTLS 用于加密数据通道，SRTP 用于加密媒体流。如果证书生成失败（在浏览器中自动处理），或者两端在 DTLS 握手过程中失败（如时钟不同步导致证书有效期校验问题），连接也会终止。

2.5 对端状态与资源问题

对端可能关闭了 RTCPeerConnection，或者媒体资源（如摄像头、麦克风）被其他应用独占访问，导致本地无法添加轨道，进而使 createOffer 失败。

示例4：完整的连接建立与错误处理流程

// 技术栈：JavaScript (WebRTC API) + 模拟信令
async function startCall() {
  const pc = new RTCPeerConnection(getIceServers());
  const localStream = await navigator.mediaDevices.getUserMedia({ audio: true, video: true });
  localStream.getTracks().forEach(track => pc.addTrack(track, localStream));

  // 收集并发送ICE candidate
  pc.onicecandidate = (e) => e.candidate && sendSignal('candidate', e.candidate);
  
  // 监听远端流到来
  pc.ontrack = (e) => { /* 将 e.streams[0] 赋值给远端 video 元素 */ };
  
  // 监听ICE状态
  pc.oniceconnectionstatechange = () => {
    if (pc.iceConnectionState === 'failed') {
      console.error('ICE失败，尝试重启...');
      // 策略1：重启ICE (ICE Restart)
      pc.restartIce();
      // 策略2：重新创建Offer并重新协商（需要信令配合）
      renegotiate(pc);
    }
  };

  // 创建Offer
  try {
    const offer = await pc.createOffer();
    await pc.setLocalDescription(offer);
    sendSignal('offer', pc.localDescription);
  } catch (err) {
    console.error('创建或设置本地Offer失败:', err);
    // 可能原因：媒体资源冲突、SDP生成内部错误
  }
}

// 处理远端发来的Answer
async function handleAnswer(answerSdp) {
  try {
    const answer = new RTCSessionDescription({ type: 'answer', sdp: answerSdp });
    await pc.setRemoteDescription(answer);
    console.log('远程描述设置成功');
    // 此时可以安全地添加之前可能已收到的远端candidate了
    flushRemoteCandidates();
  } catch (err) {
    console.error('设置远程Answer失败:', err);
    // 可能原因：SDP格式错误、与本地Offer不兼容
  }
}

三、系统性的排查与解决方案

当连接失败时，不要盲目尝试。请遵循以下步骤：

  1. 打开浏览器控制台：查看是否有明显的 JavaScript 错误或 WebRTC 的警告/错误日志。
  2. 检查信令通道：确保 WebSocket 连接正常，发送和接收的消息格式正确，并且 offer/answer/candidate 的交换顺序符合规范。
  3. 验证 ICE 服务器配置：
    • 访问 chrome://webrtc-internals（Chrome）或 about:webrtc（Firefox），查看“ICE候选”表格。检查是否收集到了 srflx（STUN）或 relay（TURN）类型的候选地址。
    • 如果只有 host 类型，说明 STUN 未生效，检查防火墙是否阻止了 STUN 查询（通常是 UDP 3478 端口）。
    • 如果连接最终状态为 failed 且没有 relay 候选，说明可能需要配置可用的 TURN 服务器。
  4. 简化与测试：
    • 首先尝试在同一局域网内的两台设备间连接，排除公网 NAT 问题。
    • 使用最简单的代码示例，逐步添加功能，定位问题引入点。
    • 测试不同的编解码器（如强制使用 OPUS 和 VP8）。
  5. 实施降级与重试策略：
    • 在 oniceconnectionstatechange 监听中，当状态变为 failed 时，可以调用 pc.restartIce() 方法触发 ICE 重启，重新收集候选并重新协商。
    • 对于更严重的错误，可以引导用户重新发起呼叫，即重新创建 RTCPeerConnection 对象。

四、应用场景、技术优缺点与注意事项

应用场景：RTCPeerConnection 是实现实时通信的核心，广泛应用于视频会议（如 Google Meet）、在线教育、远程医疗、游戏语音聊天、智能设备监控（如门铃摄像头）以及任何需要浏览器之间直接传输音视频或数据的 P2P 应用。

技术优点：

  • 原生浏览器支持：无需安装插件。
  • 强大的 P2P 能力：在理想情况下可实现端到端直连，延迟低，服务器压力小。
  • 强制加密：保障通信安全。
  • 灵活的媒体控制：可以动态添加/移除音视频轨道，适应复杂场景。

技术缺点与挑战：

  • NAT/防火墙穿透复杂：需要依赖 STUN/TURN 服务器，增加了部署和维护成本。
  • 连接建立成功率受网络环境影响：在移动网络或企业级防火墙后，成功率可能下降。
  • 开发调试复杂：涉及信令、SDP、ICE 等多层协议，问题定位困难。
  • 设备与编解码器兼容性：不同浏览器、不同设备支持的媒体能力有差异。

注意事项：

  1. 始终配置 TURN 服务器：对于面向生产环境的应用，TURN 服务器是保证连接成功率的“保险”，必须部署。
  2. 处理设备权限和变更：用户可能中途禁用摄像头/麦克风，或设备被拔出，需要通过 MediaStreamTrack.onended 等事件妥善处理。
  3. 管理连接生命周期：页面关闭或导航前，务必调用 pc.close() 释放资源。
  4. 关注 SDP 的“计划 B”与“统一计划”：旧版 SDP 语义（Plan B）和新版（Unified Plan）在处理多流时差异巨大，确保两端浏览器和信令处理逻辑兼容。
  5. 做好降级和用户体验：连接失败时，给用户清晰、友好的提示，并提供重试按钮。

五、总结

RTCPeerConnection 连接建立失败是一个多因素问题，但其根源主要集中于 信令、ICE、SDP、安全 这四个环节。排查时应像侦探一样，从控制台日志和 WebRTC 内部状态入手，优先检查 ICE 候选地址的收集情况，这是诊断网络层问题的关键。牢记“先信令交换 SDP，再交换 ICE candidate”的基本顺序，并确保为应对复杂网络环境而配置了可靠的 TURN 服务器。通过结构化的代码、完善的错误处理以及合理的重试机制，可以显著提升 WebRTC 应用的健壮性和用户体验。掌握这些排查与解决思路，你就能从容应对大部分 WebRTC 连接建立过程中的挑战。