序：通常webrtcHacks上多是长篇文章，但并非所有有趣的话题都需长篇大论。有时简短一点会更好。因此，为了向大家展示符合上述特点的主题，我们开设了一个新的“短篇系列“栏目。以下是本系列第一篇文章，主题为“完美协商”。
什么是“完美协商”，我们为何需要“完美协商”？
很久以前，WebRTC规范设计者决定将两个WebRTC端口之间的信令通信机制由应用程序负责。这意味着你的代码需要处理来回传递的SDP，并将其提供给peerConnection API。如今，WebRTC实施普遍使用Trickle-ICE，即交互式连接建立（ICE）的一种形式。该方法在端口之间不同步传递潜在网络路径，因此可以尽快建立连接。上述操作虽不同步，但对时间十分敏感。也就是说可能发生眩光情况（即双方同时进行更新导致其状态机不同步的情况）。而开发人员操作代码的方式和浏览器的不同会使情况变得更糟。
完美协商是解决这些问题的一种方法。
我们如何操作完美协商？
该方法有以下几种形式：
- 规格更新
请参阅官方说明以查看推荐的代码模式。Jan-Ivar Bruaroey在其《完美协商》这篇博客文章中对此进行了更深入的评论，并将其加以实践。
- API更新
目前开发人员正更新RTCPeerConnection API。例如Mozilla一直在致力于：
- restartIce()
- setRemoteDescription with “rollback” support
- setLocalDescription() without arguments
- Stopping and stopped transceivers
正如其发表的声明中所述，这些内容大多数适配于Firefox 70，而setLocalDescription更新计划在Firefox 74中进行。 Chrome的无参数setLocalDescription（），restartIce（）和“ rollback”有一套相似的更新计划。
- 错误修复和测试
Google的HenrikBoström提出一些未解决的问题，例如回滚错误、事件可能无法在正确的时间正确触发并实现transceiver.stop（）。Chrome在这方面更新和相关错误的跟踪操作不是很理想。
新发布的Edgium也提供了帮助。上个月，Microsoft Skype / Teams首席架构师Bernard Aboba对我发表的的Edgium评论作出了回复：
“微软在屏幕共享和完美协商方面的贡献直接帮助了Chromium。因此这不会导致Chrome和Edge之间出现任何分歧。完美协商工作（包括对回滚的支持）尚未完成，这就是某些测试现在失败了的原因。”
我可以对自己的WebRTC code做些什么？
如果你自己处理RTCPeerConnectionc ode，则至少应检查说明中的“完美协商”代码模式。在完成这项工作后，你应该可以实现更简单，更可靠的操作。
感谢Mozilla的Jan-Ivar Bruaroey和Google的HenrikBostöm提供了本文中的相关链接，并分享了完美协商当前的进展情况。
原文地址：https://webrtchacks.com/min-duration-series-part-1-perfect-negotiation/
文章作者：chad hart
