但是，这并不完美！
原因有两点：
第一点：这就是为什么我这么早就对此发表博客。我提出了3个规范说明，希望这些说明可以消除对Promise.all和“stable”测试的依赖。其实归根到底是用一种与执行rollback略有不同的API，其用于以防闪退的方式设置一个新的端描述。在某种程度上它也是重启ICE的方式，且不会干扰negotiationneeded。
第二点：关键是要编写一次代码，以抽象出该状态机。一旦正确完成操作，那么我们就不必再担心这种复杂性会影响该应用程序的其余部分。可以在应用上方标明“让行端”。现在只需在对等端连接上调用方法，而无需再担心此状态机。
如果您想知道为什么WebRTC无法自动处理此问题，很大一部分原因是有些人想要一个高级API，而其他人想要一个低级API。开发组无法生成适合所有人的“一刀切”产品。具体来说，如果不借助应用程序去解决当前体系结构中的问题，需要WebRTC定义自己的信令通道方式并将其强加给每个人，而这并不能满足大家不同的需求。
好消息是，高级别的API可以跳过这一步进行编写。这篇文章会向大家说明一种编写方法。
为什么要追求完美？
请问有多少人加入了WebRTC通话，连接失败，然后刷新页面就可以正常工作了呢？这种失误是我们无法接受的！
我们誓在改善这这种情况，就像我们决心使客户免受加诸在端连接上各种修改所需的协商的困扰一样，不管问题何时发生，并使改进生效。从我的早期测试来看，这似乎可行。我所说的句句属实。我们从测试中发现了Firefox的一些漏洞，正在努力修复。 而Chrome浏览器还处于初期阶段，尚不支持此功能，因此解决此问题还需要些时日。
这样的修复看起来很简单，其实并不是：确定何时需要协商的规范算法实际上非常复杂。例如，当你是接收端且信号状态不“stable（稳定）”时，你是无法预测pc.addTrack（track）的行为的。这取决于当时有多少未使用的收发器，一旦我们回到“stable”状态，无法确定是否需要第二轮协商。这种情况是你的手动协商代码无法处理的。
演示时间到！
如果您无意了解上述操作的工作原理，那么就可以不用读下去了，可以直接运行程序并使用其中的复选框。需要注意的是你需要在Firefox中运行，最好是使用Nightly，因为Chrome尚不支持此操作。
为了在信令方面具有逼真的代码，我们在一个iframe中设有一个对等端，而在iframe之外则有另一个对等端使用postMessage进行信令操作。
单击“结果”选项卡，然后切换各个复选框，以从两个对等端的末端（iframe的内部或外部）添加或删除媒体。这时你能够看到视频从另一端开始响应移动。请尝试查找错误（下面的示例中就有）！
（示例见原文）
一旦我们跳过按钮设置，就会有一些按钮单击处理程序可以添加/删除媒体。 向下滚动，我们会识别出我们已经介绍过的代码以及一个白噪声发生器。 这里也有一个数据通道，我们用它来操作“双噪音”的复选框。 按下此复选框将会使更改和协商几乎同时在两端进行。 大多数的漏洞（和错误）都在这儿。 我们正在努力修复他们。
原文地址：https://blog.mozilla.org/webrtc/perfect-negotiation-in-webrtc/
文章作者：Jan-Ivar Bruaroey
