TURN | WebRTC中文网-最权威的RTC实时通信平台

Prflxion——WebRTC泄露ip地址

Peer5工程师团队发现了一个WebRTC安全漏洞，我们将其归类为Prflxion。在用户使用Chrome或Edge时，该漏洞会泄露用户的本地IP地址。而该数据作为一个有价值的标识符，可能会被第三方（如广告公司或任何专门为感兴趣的人映射内部网络的人）用来准确识别、定位NAT（网络地址转换）背后的用户。该漏洞存在于所有通用操作系统上基于Chromium的浏览器（Chrome，Edge）。 2021年6月10日，Peer5向Chromium开发团队报告了该漏洞。2021年6月15日该漏洞的修复补丁发布。简介 WebRTC是一项增加浏览器实时通信和端对端通信功能的网络标准。Peer5用WebRTC把不同视频的观众连接在一起，以便更有效分配http视频流量。 WebRTC和mDNS WebRTC技术属于浏览器Javascript DOM（文档对象模型）装置的一部分。它增强了两个浏览器间建立直连的能力，并且利用连接在浏览器间发送视频等数据。为实现这种连接，浏览器必须向应用层展示附加网络功能和信息。WebRTC的连接建立在参与端交换各自网络接口的信息后。该信息包括他们的本地（直接）IP，以及用于

WebRTC中，网络抖动和往返时间哪个更重要

在测试或监控 WebRTC 应用时，网络抖动和往返时间哪个更重要呢？如果你已经拥有了自己的 WebRTC 应用程序。用户借助该应用来沟通交流。那你如何知晓用户体验如何？服务器地址是否正确？你是否正确配置了路由？你是否需要在法兰克福添加一个新服务器？是否在澳大利亚增扩规模会更好？要回答这些问题，我们需要检查应用的用户以及应用使用质量。其中，在检查WebRTC 质量时，你会遇到很多关于网络抖动、延迟和往返时间的术语。那么，使用 WebRTC 跟踪和使用 WebRTC 关注哪一个更重要？是网络抖动？还是往返时间呢？我认为两者都很重要。但不能完全下结论。让我们试着拆分这两大块，以便理解。网络 vs 端对端延迟我们可以用不同方式查看这些指标，特别是延迟和往返时间。但首先要解决的问题是：我们到底要测量什么？上图是一次 WebRTC 会话中，网络流量运作过程的简化版本。这其中没有服务器，也没有很多其他组件。沿途的每个组件都可能会增加延迟，甚至影响抖动。图中整体可分为3个不同部分： 1. 获取、播放媒体的外围设备。包括屏幕、麦克风、摄像头、扬声器等。它们都会增加固有的延迟，其中有些设

我是不是遇到了对称型 NAT

对于VoIP来说，NAT，特别是对称型NAT会产生很多问题。而WebRTC中就有解决这些问题的工具。 WebRTC可在web浏览器之间建立端对端的连接。为了做到这一点，WebRTC采用了ICE（交互式连接建立）这套技术。ICE允许某些执行NAT（网络地址转换）路由器所代表的客户端建立直接连接。（欲知详情，请参考WebRTC glossary entry。）其中最重要的是让客户端找到公共IP地址。为实现这一需求，客户端需向STUN服务器询问其IP地址。 NAT是连接我们本地个人网络和公共互联网的一个个盒子。NAT通过把我们使用的内部IP地址，转换为公共地址来实现连接。不同的NAT工作方式也不尽相同。这就使得WebRTC需要靠STUN和TURN来同时连接呼叫。有关这一点的详细背景，大家可以参考一些之前发布的相关文章，比如这篇和这篇。在学习Tsahi Levent-Levi的WebRTC架构——NAT穿透一课时，我从下面这张ppt中（重新）理解了对称型NAT的含义。如果你向两个不同的STUN服务器询问自己的公共IP地址，对称型NAT会返回两个相同的IP地址（理想情况），但实际上两个地址的

在 WebRTC 应用中，通过 Capture Handle 识别共享标签页

我一直不太赞同在演示的同时共享屏幕。大家进入视频会议应用程序，跟大家打招呼，然后开始分享自己在另一个标签或窗口的ppt。那你要看什么呢？ppt吗？但我更想面对观众并与其互动。确实，有些工具可以让你预览所分享的内容，但你仍然需要来回滑动每张ppt。理应采用一个更好的办法，那就是capture handle。 Capture Handle是origin trial中一个用于屏幕共享（getDisplayMedia）的新的API。它可以让屏幕共享app识别，与用户选择的标签相协调。 Elad Alon是一位对接webrtc.org团队的谷歌员工。他负责整理capture handle规范，并推动其通过W3C的标准化过程。在这篇文章中，Elad向我们介绍了capture handle，并列举了一些关于防止“镜室（hall of mirrors）效应”的例子。另外他也回答了我在文章开头所说，屏幕共享时切换幻灯片的问题。capture handle也有很多其他用途。下面会对此进行详述。在过去的一年里，屏幕共享逐渐成为大家生活中必不可少的一部分。其原因自然不言而喻。对于基于Web的产品，该操作

WebRTC Mesh 架构

最简单的WebRTC实例可以让你在两个浏览器之间建立一个实时的端对端连接，在其中交换个人视频、音频和数据。具体过程如图：当然，大家都知道还需要信令和几个STUN/TURN服务器来完成上述操作。目前，我们先假设这些部分都已齐全。办个派对如果我们在上述连接中加入一个用户，两个用户，三个用户，会发生什么呢？这就是被定义为多方参与的一种情况。此种情况下的规则有所不同，甚至可以说大不相同。涉及到如何处理WebRTC上的多方连接时，有三种策略可供选择——Mesh、SFU和MCU。Mesh是最简单，也可能是最常用的解决方案。今天我们要讨论的就是它。 Mesh 为了保证连接成功，使用RTCPeerConnection API的每一端都必须创建一个连接对象。这个连接对象需要添加所有相关的信息，如视频和音频流、STUN/TURN服务器地址，以及创建 Interactive Connectivity Establishment (ICE)候选者，或接收任何数据时所需的处理程序。然后，API负责使用所有已传递的数据建立连接，这其中会有一个信令处理的过程。最后，我们只需对添加到呼叫中的每一

FaceTime终直面WebRTC：deep dive实现（下）

2021-06-15更新音频数据还有一点很奇怪：音频ssrc 78925910在统计图中出现了两次，一次作为入站数据出现：另一次作为出站数据出现： RTP转储清楚地表明，服务器并没有用该SSRC发送任何音频数据包。它是浏览器在第一次调用createAnswer和setLocalDescription时产生的，随后服务器在setRemoteDescription调用中使用了它。技术上讲，这是一个SSRC冲突，浏览器应该拒绝，且这样做也没有意义。算是又一个小错误吧。但RTCP的统计数据显示，还有另外两个错误：一般不会出现如此高的抖动值。因为抖动是以秒为单位的，超过半秒就意味着糟糕的通话质量。原来，往返时间一直为零也是个错误。自上次接收者报告后，RTCP接收器报告中的时间就被设置为零了。 Main JavaScript 我们在此处找到了Main.js 文件（注：该链接有时可能失效）。 RTCPeerConnection的构造函数比较容易找到，具体如下：其中一些变量的命名很高明。MIDMap就说明FaceTime正在使用收发器的mid属性来部署，追踪参与者。Mozilla的Jan

WebRTC测试——让testing更简单（下）

目前，生成流量是很多WebRTC testing工具的开发重点。需要依靠以下两种技术的任意一种来完成。 1. 使用浏览器自动化技术，比如建立在Selenium之上。并依靠浏览器自行处理和管理所有WebRTC流量； 2. 创建合成的、预先编码的流量（或只是回传收到的内容）。这种技术主要用于大规模测试，即需要测试几十万个数据流。这时再使用浏览器的话成本过高，所以采用此种技术。 2. 用户模拟在生成WebRTC流量过程中，用户行为也是需要考虑的一部分。很多情况下，WebRTC会话不是对等的：可能有一个用户是发言人，其他用户都是观众。而在其他情况下，可能会有几位发言人，然后会直播给更多观众看。你使用的工具应该够强大，这样才能处理测试场景中的不同角色。即使在一组对等的WebRTC小组视频通话中，也需要测试屏幕共享，这意味着现在该会话中有发言人这一角色。赋予角色应不仅只对用户本身可用，用户设备如何表现，以及如何分析数据方面也应该可用。 3. 数据收集到这一步，我们已经在WebRTC中生成了流量，为各种流指定了角色。现在该来收集数据了。 WebRTC让我们看到更多有用的数据点，如：控制台

WebRTC测试——让testing更简单（上）

生成WebRTC测试很难，但细节决定成败。testRTC的WebRTC云测试以及验证平台就可轻松完成扩缩。从简单的1:1，到弄清楚如何优化大型群组视频通话，到给数千名参与者现场直播，测试WebRTC应用挑战重重。我们需要的是操作方便而又功能强大的自动化技术。与其他网络技术不同，WebRTC有三点特性： 1. WebRTC资源独占。这就导致大规模测试时分配资源变得很复杂。 2. WebRTC交互性高。涉及多人的场景需要多人参与，也就是说需要多位测试员来扩缩线上测试。 3. 用公认的web指标决定成功或失败是没有用的。WebRTC有自己的一套测试指标，需要收集和分析。随着远程通话和协作的需求不断增加，WebRTC的用户也显著激增。从一种小众技术，成长为了如今世界各地许多组织和群体完成任务都必不可少的一项技术。 2015年，testRTC发现了上述需求，投资创建了一项自助服务。主营在class平台上大规模和按需测试WebRTC。什么是WebRTC测试和WebRTC testing？ WebRTC testing本质上由web和VoIP两部分组成。一方面你需要测试基于web的应用程序。另

状态机bug一览

2019年1月29日，我们在FaceTime群聊中发现了一个严重漏洞。该漏洞使黑客能呼叫目标设备，且在没有与目标进行用户交互的情况下强制连接呼叫，这样一来，即使没有获得目标同意或目标毫不知情，黑客也能够监听其有关信息。该bug不仅运行机制奇特，造成的危害也较大。它能在没有获得代码执行的情况下强制目标设备向黑客设备传输音频，这样不寻常的漏洞前所未有。此外，该漏洞是FaceTime调用状态机中的一个逻辑bug，只需使用设备的用户界面即可激活。虽然这个bug很快就被修复了，但我从未见过由于调用状态机中的逻辑bug而发生了如此严重且容易触及的漏洞，似乎没有哪个平台预设过这种攻击场景。我不禁怀疑其他状态机是否也存在类似的漏洞。本文记录了我对各大通讯平台（包括Signal、JioChat、Mocha、Google Duo和Facebook Messenger）调用状态机的调查情况。 WebRTC和状态机大多数视频会议应用都是使用WebRTC实现的。在之前的文章中我已对WebRTC有过详细讨论。WebRTC连接是通过端与端之间在交换会话描述协议（SDP）中的呼叫设置信息来创建的，这个过程被称为信令

体验表单测试

申请体验Demo 电子邮件 * 联系电话 * 公司名称 * 行业 * … 社交电子商务赛事直播在线教育在线游戏企业协作政企服务医疗健康在线金融智能硬件 AR VR 其他

Search Results for: TURN – Page 3