WEBRTC P2P穿透不了采用RELAY策略，RELAY实现采用标准的
RFC5766(UDP Allocation)，当然少不了RFC5389，但没有实现RFC6062(TCP Allocation) RELAY采用的传输层协议，由STUN Attributes REQUESTED-TRANSPORT决定，RFC5766定义UDP ,RFC6062定义了TCP，这个REQUESTED-TRANSPOR 规定的是TURN SERVER与PEER之间的传输协议，CLIENT与TURN SERVER的协议 RFC5766规定可以为UDP,TCP,TLS;RFC6062 必须为TCP,TLS。
WEBRTC 实现RFC5766的代码为 turnport.cc/.h
1.设置SERVER 与 PEER间为 UDP传输代码：在ALLOCATE请求中指定
webrtc的前世今生、编译方法、行业应用、最佳实践等技术与产业类的文章在网上卷帙浩繁，重复的内容我不再赘述。对我来讲，webrtc的概念可以有三个角度去解释：
（1）.一个W3C和IETF制定的标准，约定了Web间实时音视频通信机制，通过该标准可开发基于浏览器的、无插件的web多媒体应用（一般是js），该标准仅设定了点对点无中心的实时会话场景，没有强制约束信令协议与内容，没有要求有媒体处理的中心服务器，主要目标是形成开发者与浏览器厂商良好的生态环境，并积极向HTML5靠拢争取被纳入进去；
（2）.一群音视频算法和网络适应性算法，这些算法囊括了视频会议几乎所有的核心技术，包括音视频的采集、编解码、网络传输、播放显示、安全等功能，还提供了操作系统系统调用跨平台封装的实现，包含Windows，Linux，Mac，Android，iOS；
（3）.一个开源工程，核心由c++实现，可通过修改、封装、提取代码等方式实现一套视频会议系统，客户端可实现为Web js、App或Windows应用程序等多种形式，服务端可实现包括业务外的所有服务，包括媒体服务、信令服务、穿墙服务、中继服务等等，这些服务稍微调整后可轻易支持分布式部署、容器部署、云部署等。
对webrtc的理解与使用，我认为有三个境界：
如果你计划在WebRTC中有多个参与者，那么最终可能会使用选择性转发单元(SFU)。webrtcHacks的撰稿人 Alex Gouaillard和他的CoSMo Software团队组建了一个负载测试套件来测量负载与视频质量，并发布了所有主要开源WebRTC SFU的结果。LiveVideoStack对原文进行的摘译。
文 / Alex Gouaillard 译 / 元宝 原文 https://webrtchacks.com/sfu-load-testing/
首先要注意一个重要的问题——问什么样的SFU是最好的就像问什么样的车是最好的。如果你只想快点，那么你应该买一辆一级方程式赛车，但这不会帮助你送孩子上学。供应商从不对这些类型的测试感到兴奋，因为它把它们的功能归结为几个性能指标。这些指标可能不是其设计标准的主要部分，而且很多时候他们并不是那么重要。特别是对于WebRTC SFU，因为您可以在SFU上加载很多流，所以可能存在有许多弹性，用户行为和成本优化的原因。负载测试也不会深入研究端到端用户体验、开发的易用性，或者所有其他能够成功实现服务的功能元素。最后，像这样发表的报告代表了一个时间点——这些系统一直在改进，所以今天的结果可能会更好。
WebRTC（Web Real-Time Communication),一个可以让用户用自己流量实现音视频实时通信的框架（APIs),支持浏览器（Firefox、Chrome、Opera）以及iOS、Android 原生系统（Poor WP,默哀）。对于觉得带宽贼贵又需要实现用户之间音视频通信的公司来说，这是一个大大的福利。本系列文章会从WebRTC基本概念慢慢说起。
官方介绍：
WebRTC is a free, open project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs.The WebRTC components have been optimized to best serve this purpose.
Our mission: To enable rich, high-quality RTC applications to be developed for the browser, mobile platforms, and IoT devices, and allow themall to communicate via a common set of protocols.
WebRTC是一个free的开源项目，该项目提供了一组可以在浏览器、手机应用平台（再次声明，目前只支持iOS和Android。）实现实时通信的简单API(s),WebRTC的目标是将实时通信过程做得最优化。
我们的任务（指WebRTC官方）：在手机应用平台、浏览器和物联网设备之间用同一组协议实现高质量实时通信。
作为一个使用 WebRTC 独立开发者或团队，怎样才能知道自己 App 的通话质量已经“达标”了呢？如何进行合理的弱网模拟测试？介绍给开发者们三个开源工具的部署、使用方法，及其各自优缺点。
如果你是长期关注 WebRTC 的资深开发者或技术爱好者，你可能留意到了，近期圈子里出了一个不大不小的话题，引得一些知名 WebRTC 技术博主纷纷发声，表明观点。
事情是这样的。
前不久，Jitsi 在其官方博客[1]上发布了一个 WebRTC 与 Zoom Web 客户端的视频通话对比测试。测试结果显示，WebRTC 的视频通话质量比 Zoom 还要好。一石激起千层浪，不少博主发表了自己的看法。
本文整理自声网数据平台首席架构师何丰在 RTC 2018 实时互联网大会的演讲内容。他的演讲内容主要包括，如何以数据来衡量实时通信质量，质量透明化背后的数据挑战，以及声网面向开发者免费推出的通信质量诊断分析产品“水晶球”（Agora Analytics）的应用与技术难点。以下为演讲实录。
我们是提供实时音视频服务的。我们希望让开发者们使用实时通信服务，就像使用水、电一样方便。用户的设备接入了我们的云服务后，就可以直接与全球其它国家和地区的用户进行实时的语音或视频互动。
在声网的实时通信云服务上，已经有很多种应用，比如直播与社交，像参加本次大会的 MeetMe 就是美国目前最大的约会社交平台；再比如教育，有很多教育类产品为国内学生与海外老师搭建了实时互动的教学平台；再比如游戏，此前游戏比较流行一起打怪升级，现在很多手游已经集成实时通信的功能，开始变得社交化。在前不久，我们已经开始为小天才儿童手表提供了实时语音、视频的服务，实际上也是 RTC 技术应用于 IoT 领域的一个典型案例。
