WebRTC“完美重新协商”碰撞问题

Question

我有一个聊天应用程序，我想扩展它的语音和视频聊天功能。基本上已经完成了，但我似乎无法通过重新协商来解决问题。

我使用了关于“完美协商”的 Mozilla 文档，但它仍然陷入软锁状态，我似乎无法修复。 问题：

用户A发送重新协商报价

• 用户B收到Offer
• 用户B发送应答
• 用户 B 在应答后立即发送重新协商报价
• 用户 A 收到应答并开始处理...
• 用户 A 收到 Offer 并放弃它，因为 Answer 仍在处理中
• 用户A完成处理答案
• 用户B陷入等待答案
处理 SDP-s 的代码：

public async createSDP() {
  await this.rtcPeerConnection.setLocalDescription();
  const sdp = this.rtcPeerConnection.localDescription;
  if (!sdp) return false;
  return sdp;
}

public async readSDP(sdp: any) {
  let ignoreOffer = false;
  try {
    const offerCollision =
      sdp.type === "offer" &&
      (this.makingOffer || this.rtcPeerConnection.signalingState !== "stable");
    ignoreOffer = !this.polite && offerCollision;
    if (ignoreOffer) {
      return false;
    }
    await this.rtcPeerConnection.setRemoteDescription(sdp);
    return true;
  } catch (err) {
    console.error(err);
  }
  return false;
}

如果 

ignoreOffer

是

true

，我尝试添加迭代，尝试 3 次，并逐渐增加延迟来处理将被删除的报价。我希望它能正确读取并发出答案，但收到“m 行顺序无效”的错误我尝试在发送重新协商报价后添加超时，以检查大约 20 秒后signalingState 是否仍处于“have-local-offer”状态，得到相同的“m-lines 顺序无效”错误。

Answer 1

用户 B 在应答后立即发送重新协商报价

我认为你可以避免这种情况。

我的猜测是，在您当前的代码中，用户 B:

收到报价并创建

rtcPeerConnection
1. 呼叫、
setRemoteDescription
2. 、

   createAnswer

   、通过网络发送将来自
getUserMedia
3. 的流添加到触发

   negotiationneeded

   事件

    的连接
   

如果翻转2和3，

negotiationneeded

不会触发，也不会发生碰撞。所以正确的顺序是：

接收报价并创建

rtcPeerConnection
getUserMedia
2. ，等待完成并将流添加到连接
setRemoteDescription
3. ，

   createAnswer

   ，通过网络发送
我认为这是最简单的方法。

否则，您可以让对等点 A 在添加来自对等点 B 的新报价之前完成处理答案。如果您直接删除它，则不会有来自 B 的视频/音频，因为媒体从未协商过。