一、项目体验
以往的AR，都是要在某个APP内才可以体验到的，例如pokemon go和QQ AR火炬传递活动。
客户端通过发送Allocate请求给STUN服务器，从而让STUN服务器为A用户开启一个relay端口。利用WebRTC实现webAR事例
2019-12-10 04:53:25WebRTC数据通道的5个用处
2019-12-10 04:51:42数据通道在WebRTC生态系统中通常扮演着二等公民的角色。WebRTC越来越受的关注是因为它能够非常简单地通过JavaScript来控制用户电脑的摄像头和麦克风。
WebRTC P2P架构中的音视频联合给了很多涉及安全的视频聊天应用很大的发展机会。远程医疗应用，浏览器上视频会议，协同工具，远程交互解决方案等等，所有这些有趣的应用都是基于WebRTC视频聊天工能。
像我们这些花费大量的时间在搭建WebRTC应用的人来说，当然很享受这些音视频的创新方面，但是我也和看重与数据通道有关的应用软件。数据通道通常也是作为次要特征来使用的。
Zoom的Web客户端如何避免使用WebRTC?
2019-12-10 04:50:51Zoom的Web客户端可以在用户不下载它们App的情况下加入会议。Chris Koehncke很高兴能看到它是如何工作的。这确实有效，不必花时间下载App.并且视频质量可以接受，对此我们愉快的讨论了半小时。
打开 chrome://webrtc-internals只看到了getUserMedia被用来获取摄像头和麦克风，但是没有看到RTCPeerConnection的使用。这激起了我的兴趣，它们是如何不用WebRTC进行通话的？
WebRTC和WebVR视频通话
2019-12-10 04:49:36
Web平台上的WebRTC并不是其唯一的媒体API。WebVR说明书于几年前被引入来为浏览器中的虚拟现实设备提供支持。目前已经变为新的WebXR设备API说明书。
今年夏天我在ClueCon，Dan Jenkin说使用WebVR,FreeSWITCH向虚拟现实环境中添加一个WebRTC视频会议流是相对简单的。FreeSWITCH是一个流行的开源电话平台，并且已经拥有WebRTC有几年时间了。WebRTC, WebVR，开源-很明显这是很好的webrtcHacks材料。
Dan是一个Google开发专家，他喜欢讲将最新的Web API和RTC App结合起来. 以下文章给出了他的代码来说明他是如何使用WebVR将FreeSWITCH Verto WebRTC视频会议转变成虚拟现实会议的。
P2P通信标准协议(四)之SIP
2019-12-09 08:05:08在前面几篇文章中我们介绍了建立p2p通信的一般协议(簇),以及一种完整的NAT传输解决方案ICE,
但是对于多用户的通信情况,还有一些通用协议来实现标准化的管理,如之前讲过的SDP和SIP等,SIP(Session Initiation Protocol),
是属于应用层的控制协议,主要用于在一个或多个参与者之间创建,修改和中止会话(sessions).会话的类型包括IP电话,
多媒体流分发和多媒体会议等.
P2P通信标准协议(三)之ICE
2019-12-09 08:04:21在P2P通信标准协议(二)中,介绍了TURN的基本交互流程,在上篇结束部分也有说到,TURN作为STUN
协议的一个拓展,保持了STUN的工具性质,而不作为完整的NAT传输解决方案,只提供穿透NAT的功能,
并且由具体的应用程序来使用.虽然TURN也可以独立工作,但其本身就是被设计为ICE/RFC5245
的一部分,本章就来介绍一下ICE协议的具体内容.
WebRTC TURN协议初识及turnserver实践
2019-12-09 07:49:23P2P通信标准协议(一)之STUN
2019-12-09 07:46:04前一段时间在P2P通信原理与实现中介绍了P2P打洞的基本原理和方法，我们可以根据其原理为自己的网络程序设计一套通信规则，
当然如果这套程序只有自己在使用是没什么问题的。可是在现实生活中，我们的程序往往还需要和第三方的协议（如SDP，SIP）进行对接，因此使用标准化
的通用规则来进行P2P链接建立是很有必要的。本文就来介绍一下当前主要应用于P2P通信的几个标准协议，主要有STUN/RFC3489，STUN/RFC5389，
TURN/RFC5766以及ICE/RFC5245。
P2P通信标准协议(二)之TURN
2019-12-09 07:45:29上一篇P2P通信标准协议(一)介绍了在NAT上进行端口绑定的通用规则，应用程序可以根据这个协议来设计网络以外的通信。
但是，STUN/RFC5389协议里能处理的也只有市面上大多数的Cone NAT（关于NAT类型可以参照P2P通信原理与实现），
对于Symmetric NAT，传统的P2P打洞方法是不适用的。因此为了保证通信能够建立，我们可以在没办法的情况下用保证成功的中继方法（Relaying），
虽然使用中继会对服务器负担加重，而且也算不上P2P，但是至少保证了最坏情况下信道的通畅，从而不至于受NAT类型的限制。TURN/RFC5766就是为此目的而进行的拓展。