WebRTC完美协商是否必要？相关技术疑问咨询

1. 完美协商概念的提出时间 #

完美协商概念大约在2017年由WebRTC核心开发者提出，早期WebRTC的基础文档和教程里确实没有这个内容，是随着WebRTC应用场景变得复杂（比如多设备连接、动态媒体变更），为解决协商状态冲突问题才逐步明确并推广的。

2. 明确Offer/Answer角色后是否还会出现冲突 #

即使明确规定了固定的Offer发起方和Answer响应方，极端场景下仍可能出现Offer冲突：比如网络延迟导致的Offer重发、业务逻辑误触发了Offer发送，或者设备异常状态下的错误协商请求。完美协商的核心价值是让PeerConnection状态机具备自我恢复能力，而非仅仅预防冲突——当意外冲突发生时，能自动回到正常协商流程，而不是直接崩溃。

3. 三方场景下的Offer冲突判定 #

这种情况属于Offer冲突。此时B的PeerConnection处于已发送Offer、等待A的Answer的状态，又收到了C发送的新Offer，打破了"一次协商周期内只有一个Offer/Answer对"的状态机规则，属于典型的协商冲突场景。

4. 三方场景下的连接结果 #

完美协商不会自动让A、B、C三者都成功建立连接。它的作用是修复B的协商状态冲突，让B能正常完成和C的连接，但和A的协商会因为状态中断而失败（除非业务层做额外处理）。如果要实现A、B、C两两连接，需要业务层为B维护独立的PeerConnection实例分别对应A和C，完美协商只是保证每个PeerConnection的协商过程不会因冲突崩溃，多设备连接的管理仍需业务逻辑来实现。

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