但是，这并不完美！
原因有两点：
第一点：这就是为什么我这么早就对此发表博客。我提出了3个规范说明，希望这些说明可以消除对Promise.all和“stable”测试的依赖。其实归根到底是用一种与执行rollback略有不同的API，其用于以防闪退的方式设置一个新的端描述。在某种程度上它也是重启ICE的方式，且不会干扰negotiationneeded。
第二点：关键是要编写一次代码，以抽象出该状态机。一旦正确完成操作，那么我们就不必再担心这种复杂性会影响该应用程序的其余部分。可以在应用上方标明“让行端”。现在只需在对等端连接上调用方法，而无需再担心此状态机。
如果您想知道为什么WebRTC无法自动处理此问题，很大一部分原因是有些人想要一个高级API，而其他人想要一个低级API。开发组无法生成适合所有人的“一刀切”产品。具体来说，如果不借助应用程序去解决当前体系结构中的问题，需要WebRTC定义自己的信令通道方式并将其强加给每个人，而这并不能满足大家不同的需求。
好消息是，高级别的API可以跳过这一步进行编写。这篇文章会向大家说明一种编写方法。
为什么要追求完美？
写在前面：如果你不必担心连接状态、闪退问题（信号冲突）、角色（你处于哪一方），就可以在实时WebRTC连接中添加和删除媒体，你会怎么做呢？不受时间和地点限制，你可以很容易地调用pc.addTrack（track，stream），并且你的连接路径只会显示在另一侧，不会有终端连接失败的风险。这是个白日梦？还有很多问题亟待解决？实际上，现在Chrome已经基本完成了协商，上述操作几乎可以运行！但是这样的操作并没有广泛应用，可能是因为“几乎”这两个字。这代表该操作有5%的时间无法工作，并且若Chrome闪退，风险太高了（无法从该操作回滚，只能运用pc.close（））。但API最初的承诺仍然有效。我们只需要一个除Firefox以外的浏览器来实现回滚，并用规范允许的方法修复一些明显的竞赛问题。
这是一种有助于操作的API！
令人惊讶的是，这在两端都有效！到目前为止，我们只是以一种方式发送媒体，但是另一端可以通过调用pc.addTrack（track，stream）以相同的方式发送媒体。这里的协商也是自动进行的。在这种情况下，提供者/应答者的角色只是颠倒了。
你可以继续对你的对等连接对象进行你所需的任何更改，API将在下一次JavaScript tick时根据需要重新协商。你再也不必担心协商问题了！
如果两端在同一时间进行更改，那就另当别论了。
那么，Glare问题呢？
“Glare”是指双方同时互相发送offer，破坏了两端的状态机。他们的线路交叉缠绕在一起。就像你和朋友同时开始说话，“你听说了……吗？啊，你先说吧！”计算机都会持续这样做且永远不会停止。除非这台计算机没有神经网络。
所有操作都无法进行了，只能回到手动协商！ ——等等，让我们看看是否可以修复这个问题。
Rollback解决远程更改问题
Glare是一个应用问题，因为我们可以用多种方法解决它。例如：如果我们使用外数据通道，使所有更改始终仅来自一端，则可以完全避免Glare问题。但我们使用的这个API很难缠，但我们距离解决问题只有一步之遥了。因此，我们使用Rollback来节省时间，旨在达成完美的协商。
礼貌让行
简而言之，我们将使其中一端“礼让”一些，对另一端说“对不起，您先请！”也就是说，其中一端会拒绝收到的offer。我们很幸运，因为这是“rollback”的作用：
人类一直以来都在努力寻找与别人沟通的新方式，但即使我们不断获得进展，像共享文件这种至关重要的事情仍然非常繁琐。我们总是需要将文件上传到服务器上，然后再发回给我们以备后用。所以我们需要面对现实，文件传输并不像发送消息给对方那样简单，总会涉及到一些其他方面的问题。但是，由于WebRTC数据通道所提供的能力，这种情况正在发生变化。在本篇文章中，我希望通过一个简单的点对点连接来建立聊天以及建立基本的文件传输，为你提供一个更清晰的WebRTC数据通道工作方式。
如果你允许多人加入WebRTC通话，你可能会以SFU结束。计划如何分配容量比较困难-通常会进行估计，SFU应该放在哪里，它们将会消耗多少带宽，你需要何种服务器。
为了帮助网络架构和WebRTC工程师作出决定，Alex博士和他的CoSMo Softwae团队将负载测试元件放在一起来测量负载和视频质量。他们公布了所有主流的开源WebRTC SFU的测试结果。这个元件基于KITE并且在webrtc.org上用来显示互通状态。CoSMo团队还开发了一个基于机器学习的视频质量评估框架来优化实时交流。
首先注意：问哪种SFU是最好的就相当于问哪种汽车是最好的。如果你只要求速度快，那你应该买F1赛车，但是它不能帮助你送孩子上学。供应商从来不会对这些测试感兴趣因为它将它们的功能仅仅总结成一些性能指标。这些指标可能在它们的测试中不起主要作用，并且也不是判别产品好坏的主要标准。对于WebRTC SFU,仅仅因为SFU可以负载许多流，但是可能还有别的限制条件，用户行为，花费优化等原因使得他们不能这样做。负载测试同样不会深究用户体验，开发难度，或其它对服务的成功有帮助的部分。
当建立花费模型时，有很多情况我本人都想获得数据。Alex和他的团队已经做了很多深度工作，这是WebRTC开源生态系统逐渐成熟的一个好的象征。这个测试并不完美，但是我相信它会对WebRTC社群具有参考价值。
01WebRTC基础结构介绍
自从Google于2011年发布WebRTC以来，WebRTC一直是一个能够将互联网浏览器转换为强大的多媒体引擎的颠覆性技术。 WebRTC汇集了先进的实时通信技术，包括：先进的音视频编解码器（Opus和VP8/9），强制加密协议（SRTP和DTLS）和网络地址转换器（ICE＆STUN）。
根据最初的定义，WebRTC被指定为P2P（peer-to-peer）技术。自成立以来，WebRTC已经大大降低了Web开发人员通过简单的Java API构建实时通信应用程序的难度。但要清楚，WebRTC是一种技术，而不是一个完整的应用程序或服务。
虽然WebRTC最初被设想为纯粹的P2P技术，但许多日常业务应用程序需要集中式媒体功能，通过P2S（peer-to-server）架构提高可靠性、效率或扩展性。对于P2P和P2S架构之间的问题对于构建WebRTC应用程序很重要。
02P2P到P2S
WebRTC旨在通过其浏览器（也称为P2P）在客户端之间直接发送媒体流。在P2P架构中，客户端建立通信之前，首先需要建立到应用服务器（有时也成为信令服务器）的信令连接。而 WebRTC规范中没有规定信令方法或协议，它允许采用现有方法（SIP，WebSockets，XMPP等）或实现专有信令过程。应用服务器保存业务逻辑，并作为会话描述协议（SDP）交换的中介。一旦SDP交换完成，两个客户端之间的直接媒体通信即可开始。
当你入门 WebRTC 之后，很快就会接触到一个名词，叫做：SFU，你可能很容易就在网上寻找到很多 SFU 的开源实现，并并兴致勃勃地开始编译、部署和测试这些服务器，但是可曾想过，为啥我们的 WebRTC 应用需要 SFU 服务器 ？
1 WebRTC P2P 通话的网络模型
webrtc的前世今生、编译方法、行业应用、最佳实践等技术与产业类的文章在网上卷帙浩繁，重复的内容我不再赘述。对我来讲，webrtc的概念可以有三个角度去解释：
（1）.一个W3C和IETF制定的标准，约定了Web间实时音视频通信机制，通过该标准可开发基于浏览器的、无插件的web多媒体应用（一般是js），该标准仅设定了点对点无中心的实时会话场景，没有强制约束信令协议与内容，没有要求有媒体处理的中心服务器，主要目标是形成开发者与浏览器厂商良好的生态环境，并积极向HTML5靠拢争取被纳入进去；
（2）.一群音视频算法和网络适应性算法，这些算法囊括了视频会议几乎所有的核心技术，包括音视频的采集、编解码、网络传输、播放显示、安全等功能，还提供了操作系统系统调用跨平台封装的实现，包含Windows，Linux，Mac，Android，iOS；
（3）.一个开源工程，核心由c++实现，可通过修改、封装、提取代码等方式实现一套视频会议系统，客户端可实现为Web js、App或Windows应用程序等多种形式，服务端可实现包括业务外的所有服务，包括媒体服务、信令服务、穿墙服务、中继服务等等，这些服务稍微调整后可轻易支持分布式部署、容器部署、云部署等。
对webrtc的理解与使用，我认为有三个境界：
