但是，这并不完美！ 原因有两点： 第一点：这就是为什么我这么早就对此发表博客。我提出了3个规范说明，希望这些说明可以消除对Promise.all和“stable”测试的依赖。其实归根到底是用一种与执行rollback略有不同的API，其用于以防闪退的方式设置一个新的端描述。在某种程度上它也是重启ICE的方式，且不会干扰negotiationneeded。 第二点：关键是要编写一次代码，以抽象出该状

这是一种有助于操作的API！ 令人惊讶的是，这在两端都有效！到目前为止，我们只是以一种方式发送媒体，但是另一端可以通过调用pc.addTrack（track，stream）以相同的方式发送媒体。这里的协商也是自动进行的。在这种情况下，提供者/应答者的角色只是颠倒了。 你可以继续对你的对等连接对象进行你所需的任何更改，API将在下一次JavaScript tick时根据需要重新协商。你再也不必担心协

写在前面：如果你不必担心连接状态、闪退问题（信号冲突）、角色（你处于哪一方），就可以在实时WebRTC连接中添加和删除媒体，你会怎么做呢？不受时间和地点限制，你可以很容易地调用pc.addTrack（track，stream），并且你的连接路径只会显示在另一侧，不会有终端连接失败的风险。这是个白日梦？还有很多问题亟待解决？实际上，现在Chrome已经基本完成了协商，上述操作几乎可以运行！但是这样的