WebRTC中的完美协商(三)

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

WebRTC中的完美协商(二)

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

WebRTC中的完美协商(一)

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