WebRTC连接建立疑问：Offer/Answer流程及negotiationneeded无限循环问题

问题复现步骤 #

• 步骤1：peer1 创建 Offer 并发送给 peer2，peer2 接收后创建 Answer 返回给 peer1。双方均添加媒体轨道并发送，但此时仅 peer2 能收到 peer1 的视频（触发 track 事件），peer1 无法收到 peer2 的视频（无 track 事件触发）。
• 步骤2：阻止后续协商（不处理触发 createOffer 的 negotiationneeded 事件）。
• 步骤3：允许 peer2 创建 Offer 并重复协商流程后，peer1 能收到 peer2 的视频（触发 track 事件）。
• 步骤4：若不阻止 negotiationneeded 事件，该事件会在 peer1 和 peer2 间交替触发，导致 RTCPeerConnection.createOffer() 被持续调用，形成无限协商循环，尽管此时双方都能显示对方视频。

疑问解答 #

1. 是否需要双方各自创建 Offer 才能互相显示视频？仅 peer1 发 Offer、peer2 发 Answer 是否足够？步骤3是否必要？ #

不需要双方各自主动创建Offer，单轮Offer-Answer协商完全可以实现双向视频流。你遇到的peer1收不到peer2视频的问题，大概率是因为第一轮协商时peer2添加媒体轨道的时机错误：

• 如果peer2是在收到peer1的Offer之后才添加本地轨道，此时Offer里并没有包含peer2的媒体能力信息，peer1的PeerConnection不知道要接收peer2的流，自然不会触发track事件。
• 正确流程是：双方都要在创建Offer/Answer之前，先把本地媒体轨道添加到PeerConnection中。这样第一轮协商的SDP就能包含双方的媒体参数，单轮协商后即可双向互通，步骤3的二次Offer操作完全没必要。

2. negotiationneeded事件何时触发？步骤4中导致其持续触发的原因是什么？ #

negotiationneeded事件触发的核心条件是：PeerConnection的本地状态（比如媒体轨道、ICE配置等）发生了变化，而当前的远程描述（remoteDescription）无法匹配这个新状态，需要重新协商更新SDP。

步骤4中无限循环的常见原因：

• 协商流程不完整：比如只设置了本地描述但未成功交换并设置远程描述，或者设置描述的顺序错误（比如先设置remoteDescription再设置localDescription），导致PeerConnection一直处于需要协商的状态。
• 协商过程中重复修改状态：处理negotiationneeded事件时，在协商未完成的情况下又修改了PeerConnection的媒体状态（比如重复添加轨道），导致协商结束后再次触发negotiationneeded。
• Firefox 112特定行为：该版本对媒体轨道变更的敏感度较高，如果在协商过程中调整轨道，可能会触发额外的协商事件。需确保每次协商都完整走完「本地Offer→远程Answer→双方完成描述设置」的流程，且协商期间不要修改媒体状态。

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