作者：Philipp Hancke（原文链接） 翻译：刘通 最近我花了很多时间在分析数据上。这是我业余时间所进行的项目，这些工作也能帮助我解决bug问题。我从分析数据中得到的收获之一就是发现了最近在Linux上Firefox 47的倒退影响了Firefox如何收集TURN/TCP候选。“Bugzilla”上有包括Mozilla的迅速反应的全部内容。 有一天晚上我把下面这一段代码粘到了JS控制台中： 这段代码的功能是生成端到端连接，以及从我们的一个TURN服务器中采集TURN候选项。现在…它在我的Linux机上运行不了。我换了一台Windows系统的电脑，结果它运行的相当好。但是在Linux上，只要是指定IP地址而不是使用主机名，这段代码也能工作。也许只有我会遇到这个问题？ &nbs
作者：Levent-Levi（原文链接） 翻译：刘通 你不会相信在TCP上的TURN会如何改变WebRTC在网络上的表现。 我之前在BlogGeek.me上写了一篇关于使用TURN以及不要依赖公共IP地址的重要性的文章。但是在那篇文章中没有包括的内容是，TCP上的TURN会如何改变WebRTC的表现，现在让我们来好好把它讲清楚。 这就是为什么我会坐下来花时间在APPRTC上，使用1080p分辨率的摄像头作为输入，通过testRTC来看我周围的网络状况，并且分析最终我们获得的实验报告。 我想与你们分享的是四种不同的网络情况： #1—不存在丢包的P2P通话  
作者：Tsahi Levent-Levi（原文链接） 翻译：刘通 很遗憾的通知您。。。是的。。。 这是我最近突然想到的问题，而且令我惊讶的是这个问题并不是那么容易想出答案，这也让我所开的WebRTC架构课程更加的有必要参加了。有一家公司认为他们既然有在公共IP地址上的媒体服务器，所以应该就不再需要运行TURN服务器了。但显然，这么做只会使他们的服务的连接率降低。 在我写这篇文章的时候，这种事情很常见，仅仅在去年我就遇到了运营商的三种做法使他们自己服务的连接受到不好的影响： 1.他们根本不用TURN，完全依赖于在公共IP地址上的媒体服务器 &n
Philipp Hancke 我在NoJitter上读到了一篇很有意思的文章，是讨论Cisco部署Spark的方法。通过把媒体服务器铺设在离用户近的数据中心内，Cisco希望所有参与用户的延迟都保证在150毫秒之内。 仿照Dag-Inge的博客中讨论TURN服务器决定连接设定时间，我也在考虑我们是不是也能通过连接时间的长短来告诉我们TURN服务器是部署在正确的地点，或者我们是否需要改善我们的部署状态。毕竟，就像我之前写过的，这类运行设备是WebRTC服务中最重要的方面之一。 我们目前在appear.in的部署策略是基于负载的。在所有我们能够使用的AWS数据中心，我们都部署了至少一个TURN服务器，检测着流量以及当一个实例太过于拥挤的情况下启用其他实例。之后我们通过路由器53来将客户路由到最近的TURN服务器。  
延迟最小化 遵循下面几点减少数据包从A到B传输的时间可以增加通话质量。 传输POP的地理距离 当我们讨论传输的时候，必须注意这些事情：出于传输POP的原因要知道用户在哪里，我们在POP之间用什么做回程，以及当质量受影响之后该怎么处理。举个例子： # Alice在波士顿想要打电话给在香港的Bob # Bob的防火墙限制VoIP数据流，所以他需要使用TURN服务器 # 所使用的TURN服务器在德克萨斯 在上面这个例子中，通话需要一路传到德州来进行连接，这就增加了延迟也破坏了通话质量。如果TURN网络已经连入了德国和纽约，那么系统就需要对比这些不同地点之间的端到端延时，来选择一条延时最低的线路。通常都是连入最近的点，但是不是所有的情况都这样。地理上分布开的TURN网络会给出更多的低延时选择。 传输回程线路 下一个问题是，“传输通信数据如何到其他传输POP端，以及之后如何到达远端用户这个终点？”一个词来回答就是“回程（backhaul）”。我们需要一个快速的，能回复的，以及倾向使用私人网络连接这些POP。 服务质量（QOS）以及监控 我们可以依靠
Know Where to ‘TURN’ When Deploying WebRTC Eric Lagerway 12%，这就是Callstats.io的CEO Varun Singh，告诉WebRTC Conference-in-Conference大会上的听众WebRTC通话失败的比例。对于那些失败的通话，有22%的通话需要某些形式的媒体传输。造成12%这个比例的主要原因是因为网络工程师们没有考虑到NAT防火墙穿透，当搭建很多RTC网络的时候，这是对企业部署十分重要的。 关于NAT和防火墙穿透 NAT一直以来都是VoIP服务质量的破坏者，因为它会改变VoIP设备所需要寻址访问的IP地址和端口。与此同时，为了安全起见，一些防火墙会阻挡某些类型的传输。但是NAT穿透和媒体传输产品使得VoIP和WebRTC数据包能够穿透多数的企业防火墙。 简单地说，这就意味着用户可以连接并听到另一端使用者所说的话了—对其自己来说将NAT穿透作为你企业WebRTC或者UC网络设计战略的一部分也是十分有说服力的原因。传统方式是通过会话边缘控制器（SBCs）来完成，但是We
iOS系统 我们尝试用iOS的本地桥接机制进行初始化。但Olm.h和Olm.mm包含模块实现起来会更简单，其中jsiadapter::install在setBridge方法里被调用，暴露host函数。 暴露host函数 如上所述，Android和iOS的专有代码最终都会调用跨平台的jsiadapter::install方法。C++方法也在这里被暴露。即JS对象被设置在jsiRuntime.global上，其方法直接调用到了C++代码中。 通过一个全局变量，上述代码中的对象就可以在JS端被访问。就我们的用例来说，一个对象就足够了。但如有必要，无论有多少对象都可以在这里暴露，且不用改变平台的专有代码。 向暴露对象添加方法 此处暴露了两个方法：createOlmAccount和createOlmSession，都返回HostObjects。 HostObject HostObject是一个可以在JS运行时注册的C++对象。即暴露的方法可以从JS代码中调用。但它也可以在JS和C++之间来回传递，同时仍是一个完全可操作的C++对象。 就我们的用例来说，AccountHostObject和Sess
很久没有查看Google Meet的webrtc统计数据了，所以上周我趁开会的时候看了看，有哪些最新的变化被添加进来了。 P2P连接 我检查的第一个变化是：如果线上会议里只有两个参与者，Google Meet是否仍使用P2P连接。令人惊讶的是，过去会议是包含P2P支持（有关P2P-SFU过渡的讨论）的，但现在已经被移除了。 这会增加基础设施的成本（对Google来说不是什么大问题），和一对一呼叫的端对端延迟。但考虑到Google Meet可能是部署在许多接入点上，所以可能增长不大。而且移除之后不必再处理另一种类型的连接和P2P-SFU过渡，操作更简单了，所以移除它看起来是合理的。 ICE Candidate和（NO）TURN服务器 Google Meet不再配置任何ICE服务器，他们的服务器为IPv4、IPv6和UDP（随机端口）+TCP（与UDP相同的随机端口）+UDP（3478端口）+SSLTCP（443端口）这几类提供candidate。 以下是iceServers的配置，里面有空字符串。 其实不用TURN服务器不会有特别大的影响。因为这些服务器都支持SSLTCP，之前也在其他应
目前我们看到了很多软件服务、基础设施服务、平台服务、通信平台服务、视频会议服务等等，那么是否能提供游戏服务呢？现在已有一些云游戏方面的尝试，其中最出名的就是谷歌最近推出的Stadia。虽然Stadia 能够玩转WebRTC，但是其他游戏平台能否以同样的方式把WebRTC玩起来还尚未可知。 Thanh Nguyen建立了开源项目CloudRetro，来测试上述想法是否可行。CloudRetro以基于Go的最流行WebRTC库——pion而建立。在本篇文章中，Thanh介绍了他是如何建立该项目，以及他在过程中收获的经验和教训。 简介 去年，谷歌官宣了Stadia。我震惊于这个想法既独特又创新。但我心存疑虑，以目前的技术水平，怎么可能实现这个项目呢？因为想要解密这个技术，我创建了一个开源版本的云游戏。效果非常好。下文中我会分享自己过去一年在这个项目上的探索经历。 为什么云游戏是大势所趋 我认为云游戏不仅会很快引领新一代游戏的发展，也会引领计算机科学其他领域的发展。云游戏是客户端/服务器模式的巅峰之作。它通过把游戏逻辑放在远程服务器上，把图像/音频流传输到客户端这些操作，最大化了后端控制，前端
很多人都试图实现一个酷炫新功能——背景分割。虚拟背景已经风靡一段时间了。我们所说的“分割”，不是在用户身后插入一个新的背景，而是完全移除他的真实背景，是允许视频软件把每个用户放进一个共享的屏幕里，或者说出现在一个共享环境中。这个功能还没有一个通用的名字。Zoom称之为沉浸式视图（Immersive View）；微软称其为Together Mode。RingCentral称其为overlay。也有人叫它虚拟绿屏（Virtual green screens ）或者新闻播报员模式（newscaster mode） 我想在浏览器中实现背景分割这一功能。不仅要把用户的自视图的背景变成透明的，也要让用户通过WebRTC对等连接，发送给其他人的视图背景分割。WebRTC确实使实现这一功能变得很容易。而像WebRTC Insertable Streams、Breakout box等新的API可以助力该功能更加高效。接下来我会介绍一些方法和发现。你也可以点击此处查看演示。 POC 首先，我会从代码POC开始，之后运用不同场景下的实验形成更全面的playground。你可以在https://gi
WebRTC 中文社区由
运营