有奖小调查

3 分钟回答 几 个小问题,让内容更符合你的 WebRTC 学习与开发期望。
每个月最后一天会随机抽出 5 名获奖者,并通过邮件联系送上奖品。
填写问卷

短篇系列一:完美协商

序:通常webrtcHacks上多是长篇文章,但并非所有有趣的话题都需长篇大论。有时简短一点会更好。因此,为了向大家展示符合上述特点的主题,我们开设了一个新的“短篇系列“栏目。以下是本系列第一篇文章,主题为“完美协商”。

什么是“完美协商”,我们为何需要“完美协商”?

很久以前,WebRTC规范设计者决定将两个WebRTC端口之间的信令通信机制由应用程序负责。这意味着你的代码需要处理来回传递的SDP,并将其提供给peerConnection API。如今,WebRTC实施普遍使用Trickle-ICE,即交互式连接建立(ICE)的一种形式。该方法在端口之间不同步传递潜在网络路径,因此可以尽快建立连接。上述操作虽不同步,但对时间十分敏感。也就是说可能发生眩光情况(即双方同时进行更新导致其状态机不同步的情况)。而开发人员操作代码的方式和浏览器的不同会使情况变得更糟。

完美协商是解决这些问题的一种方法。

我们如何操作完美协商?

该方法有以下几种形式:

  1. 规格更新

请参阅官方说明以查看推荐的代码模式。Jan-Ivar Bruaroey在其《完美协商》这篇博客文章中对此进行了更深入的评论,并将其加以实践。

  1. API更新

目前开发人员正更新RTCPeerConnection API。例如Mozilla一直在致力于:

正如其发表的声明中所述,这些内容大多数适配于Firefox 70,而setLocalDescription更新计划在Firefox 74中进行。 Chrome的无参数setLocalDescription()restartIce()“ rollback”有一套相似的更新计划。

  1. 错误修复和测试

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

 

填写常用邮箱,接收社区更新

WebRTC 中文社区由

运营