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

WebRTC的NAT及防火墙简介（上）

大多数人开始编程或构建结构时，首先考虑到的是性能问题。开始时，他们可能会假设网络环境平稳，可靠且安全。但实际情况往往是，演示或实验会在并非像实验室那样友好的环境下开展，突然你发现实验没有正常运行，质量问题层出不穷，或者是你的系统被黑客入侵。这时你会感觉回到了实验设计的“第2阶段”，需要倾尽全力来修复漏洞。值得庆幸的是，WebRTC配备了一套内置于引擎中的鲁棒性很强的工具，它可以使Web开发者在“执行”WebRTC任务时应对自如。而在WebRTC的标准工作中，这套工具仍在不断改进。希望此文能作为详细研究这些工具的入门篇供大家学习。诚然，虽然WebRTC旨在使这套工具完全独立，所以开发人员不必关心其中缘由。但是对于那些对这套工具好奇的人、与WebRTC合作构建媒体编码器的人、或者那些努力解决WebRTC互操作性问题的人（句子太长，换口气。），我们将从WebRTC如何解决NAT和防火墙穿越的问题说起。这里我们主要使用三种工具，分别是ICE，STUN和TURN。为了更透彻理解这些工具，笔者认为最好从NAT的基础知识开始讲起。如果您是NAT行家，请多担待。本文只是一次简单的入门科普。因为我希

二分浏览器错误

当大规模运行WebRTC时，最终会以遇到问题和频繁的回归结束。能够快速识别出问题所在是防止Chrome Stable中的归档降级或调整自己代码以避免问题的关键。Chrome的bisect-builds.py工具使这个过程比你想象中容易得多。来自appear.in的Arne为你提供了一个示例，说明他是如何使用它解决最近出现的问题。本文中，我将会逐步解释Chrome的更改是如何触发appear.in中的错误，以及我们如何确定更改的确切内容。在WebRTC的基础上构建应用程序有好处也有弊端。显而易见的好处是你可以利用大量的使WebRTC成为现在样子的工作成果。然而，这也有弊端。应用程序的正确运行取决于支持WebRTC技术的正确操作，以及应用程序代码与技术之间的正确交互。当这种交互产生缺陷时，这些缺陷可能是非常明显，非常模糊，或者介于两者之间。这是一个既不明显也不介于两者之间的情形。问题所在这绝不应该发生故事开始于我们的支持专家Ashley去讨论遇到奇怪事情的客户的问题。他们报告说，最近他们在通过公司防火墙传输视频时遇到了问题。音频很好，视频通过防火墙进入公司网络就好了。但是，防火墙

WebRTC 入门教程（四）| iOS 端如何使用 WebRTC

之前，我已经写过 Android 端如何使用 WebRTC 1 的文章。在那篇文章中，我向大家介绍了在 Android 端是如何使用 WebRTC 进行音视频通话的。今天，我们再来看看 iOS 端1对1音视频实时通话的具体实现。 iOS 端的实现逻辑与 Android 端基本相同，最大的区别可能是语言方面的差异啦！所以，下面我基本上还是按照介绍 Android 端一样的过程来介绍 iOS 端的实现。具体步骤如下：权限申请引入 WebRTC 库采集并显示本地视频信令驱动创建音视频数据通道媒体协商渲染远端视频通过上面几个小节，全面介绍如何在iOS端如何使用 WebRTC。申请权限首先，我们来看一下 iOS 端是如何获取访问音视频设备权限的。相比 Android 端而言，iOS端获取相关权限要容易很多。其步骤如下：打开项目，点击左侧目录中的项目。在左侧目录找到 info.plist，并将其打开。点击右侧看到 “+” 号的地方。添加 Camera 和 Microphone 访问权限。下面这张图更清晰的展现了申请权限的步骤：通过以上步骤，我们就将

WebRTC入门教程(三) | Android 端如何使用 WebRTC

在学习 WebRTC 的过程中，学习的一个基本步骤是先通过 JS 学习 WebRTC的整体流程，在熟悉了整体流程之后，再学习其它端如何使用 WebRTC 进行互联互通。我们已经在前面分享了两篇教程：第一篇教程：信令服务器搭建第二篇教程：STUN/TURN服务器搭建本文将讲解 Android 端是如何使用WebRTC的，至于 P2P 穿越、STUN/TURN/ICE、RTP/RTCP协议、DTLS等内容不做讲解。如果有任何疑问，可以在社区与我交流。申请权限我们要使用 WebRTC 进行音视频互动时需要申请访问硬件的权限，至少要申请以下三种权限： Camera 权限 Record Audio 权限 Intenet 权限在Android中，申请权限分为静态权限申请和动态权限申请，这对于做 Android 开发的同学来说已经是习以为常的事情了。下面我们就看一下具体如何申请权限：静态权限申请在 Android 项目中的 AndroidManifest.xml 中增加以下代码: … <uses-feature android:name=”android.hardware

撸一个多人视频聊天 — 前端 WebRTC 实战（一）

前言【从头到脚】会作为一个系列文章来发布，它包括但不限于 WebRTC 多人视频，预计会有： WebRTC 实战（一）：也就是本期，主要是基础讲解以及一对一的本地对等连接，网络对等连接。 WebRTC 实战（二）：主要讲解数据传输以及多端本地对等连接、网络对等连接。 WebRTC 实战（三）：实现一个一对一的视频聊天项目，包括但不限于截图、录制等。 WebRTC + Canvas 实现一个共享画板项目。作者开源作品 Vchat — 一个社交聊天系统（vue + node + mongodb） 6 的系列文章因为文章输出确实要耗费很大的精力，所以上面计划不一定是这个发布顺序，中间也会穿插发布其它方向的文章，如 Vue、JavaScript 或者其他学习的主题。在文章里，会把我自己遇到过的一些坑点重点提示大家注意，尽量让大家在学习过程中少走弯路。当然，我的也并不是标准答案，只是我个人的思路。如果大家有更好的方法，可以互相交流，也希望大家都能有所收获。在这里也希望大家可以关注一波，你们的关注支持，也能激励我输出更好的文章。本文示例源码库 webrtc-str

视频会议的开发与探索（一）：WebRTC的狂野世界

WebRTC的狂野世界在过去的五年中，已经有太多的方式使得网页和App中支持视频会议。 Facebook,WhatsApp,FaceTime和Signal是其中几种用户可以用来在网络中进行视频，音频通话的方式。尽管很多研究已经开始转为对视频会议的加密和隐私保护，关于这些平台的易受攻击程度的信息却很少。我们查阅了三个最为广泛使用的视频会议实现方式。在本文中，我们会对此描述。这一部分将会讨论的WebRTC的分析。第二部分将会讨论对FaceTime的分析。第三部分将会讨论WhatsApp.第四部分将会描述一些对WhatsApp不起作用的攻击形式。最终，第五部分，将会讨论视频会议的未来和开发者应该如何使得自身WebRTC实现更安全。典型视频会议结构所有的视频会议实现至少要允许网络中任意两点的两点连接，来传输音频流。同时要求可靠性，和视频音频的质量，带来了很多挑战。首先，对于某一点，它需要找到其它任意一点并且建立连接，无论是NAT还是其它网络结构。接着它们需要交流，即使处于不同平台，App或浏览器。最后，它们需要保持音频视频质量，即使带宽较低。几乎所有视频会议解决方案都趋向于一个简单架

使用级联SFU提高媒体质量和规模

部署WebRTC的媒体服务器有两个主要挑战，从一台服务器开始扩展，并且优化参加会议的用户的媒体延迟。尽管简单的碎片化方法像‘将X会议中的所有用户发送到服务器Y’容易实现水平扩展，在用户体验中，媒体延迟是一个关键因素，在这方面，此方法还远远不能达到最优效果。将视频会议分布在距离用户很近的许多服务器上并且保持相互连接，同时解决了两个问题。来自Jitsi团队的Boris Grozev深度描述了级联SFU存在的问题并且展示了他们的解决方法和他们遇到的其它问题。实时交流的App非常依赖网络环境，例如吞吐量，延迟，丢失。低比特率导致低视频质量，导致了视频音频中的传输延迟更高。丢包可以导致视频跳帧，进而导致‘波浪音’和视频冻结。由于这些原因，在会议中，在两个端点之间选择最优路径是很重要的。当只有两个参与者时，这很直接—WebRTC使用ICE协议在两端建立连接，交换多媒体。如果可能的话，两端直接连接，不然的话，在少数情况下使用TURN传递服务器。WebRTC支持分解域名来获得TURN服务器地址，这使得选择基于DNS的本地TURN服务器相对简单，例如，使用AWS Route53的布线选项。然而，

WebRTC vs. Zoom 之外：WebRTC 的弱网模拟测试

本文为转载内容，原作者：声网Agora微信公众号（shengwang-agora）作为一个使用 WebRTC 独立开发者或团队，怎样才能知道自己 App 的通话质量已经“达标”了呢？如何进行合理的弱网模拟测试？介绍给开发者们三个开源工具的部署、使用方法，及其各自优缺点。如果你是长期关注 WebRTC 的资深开发者或技术爱好者，你可能留意到了，近期圈子里出了一个不大不小的话题，引得一些知名 WebRTC 技术博主纷纷发声，表明观点。事情是这样的。前不久，Jitsi 在其官方博客[1]上发布了一个 WebRTC 与 Zoom Web 客户端的视频通话对比测试。测试结果显示，WebRTC 的视频通话质量比 Zoom 还要好。一石激起千层浪，不少博主发表了自己的看法。看似是在挑事，但 Jitsi 出此一举完全事出有因。 Jitsi 是一个开源项目，可帮开发者在 Web 、Windows、Linux、Mac OS X、Android 平台上实现实时的语音、视频通话应用。有很多独立开发者在基于这套代码开发自己的视频通话应用。这一切，都是建立于 WebRTC 的基础之上实现

Zoom的Web客户端如何避免使用WebRTC?

Zoom的Web客户端可以在用户不下载它们App的情况下加入会议。Chris Koehncke很高兴能看到它是如何工作的。这确实有效，不必花时间下载App.并且视频质量可以接受，对此我们愉快的讨论了半小时。打开 chrome://webrtc-internals只看到了getUserMedia被用来获取摄像头和麦克风，但是没有看到RTCPeerConnection的使用。这激起了我的兴趣，它们是如何不用WebRTC进行通话的？为什么Zoom不使用WebRTC? Zoom与WebRTC的关系很难说清楚，就像网站上的陈述一样： Jitsi的伙伴对此进行了比较。Tsahi Levent-Levi对此也进行了有用的评论。让我们快速看看在某些有趣的情况下的‘特性’—–在Chrome浏览器中运行。 Zoom Web客户端 Chromes网络开发工具很快展现出两点： WebSockets被用来传输数据存在wasm文件 Wasm文件名快速产生了GitHub目录，在目录里，与其它JavaScript元素并存。这些文件和产品中所用的文件几乎相同。 WebSocket上的媒体

Messenger没有被强制监听但。。。

八月以来，Reuters报道了FBI和Facebook之间关于窃听Messenger通话的秘密合法斗争。The verge网站在2015年关于Messenger逆向工程的文章中经过分析发现了一系列的问题。很难找到与此相关的技术信息，因此我无法深入交流关于窃听的具体细节。 Reuters现在宣布Facebook不再被强制监听Messenger通话，并且FBI声明：目前没有实际的方法可令执法部门监测通话。这对于注重隐私的用户来说是个好消息，但是我决定从新的角度分析，对于Facebook不再监听这件事我的发现使我吃惊。 Messenger和WebRTC 我们将2015年Messenger和它对WebRTC的使用作为我们黑盒探索系列的一部分。它使用了Google的开源webrtc.org library并且做了一些修改。对于App之间的通话它还使用了SDES机制来加密。 SDES vs DTLS-SRTP和监听 WebRTC规范明确说明WebRTC必须不能使用SDES。自从2013年Eric Rescorla的IETF展示以来，对此的技术论证就没有改变。在那以前，WebRTC

Search Results for: TURN – Page 6