webrtc流媒体转发服务器
定义
难点
建立连接
如何转发媒体流
如何高效转发媒体流
转发后如何保证视频质量
定义
由于webrtc是基于P2P技术的一个协议栈，大多数情况下能满足1-5人的同时并发音视频通讯。但是对于多于5人乃至10、20人的并发，使用P2P技术会造成终端设备无法承受负荷。因此需要将P2P模式改造成能适应大量并发模式，即媒体转发服务（MCU）。
webrtc流媒体转发服务器
2020-06-23 13:51:52实际中的WebRTC：STUN，TURN以及信令（五）
2020-06-23 13:45:50NAT给设备提供了一个IP地址以使用专用局域网，但是这个地址不能在外部使用。由于没有公用地址，WebRTC对等端就无法进行通信。而WebRTC使用 STUN来解决这个问题。
STUN服务器位于公共网络上，并且有一个简单的任务：检查传入请求的IP地址（来自运行在NAT后面的应用程序），并将该地址作为响应发送回去。换句话说，应用程序使用 STUN服务器从公共角度发现其IP:端口。这个过程使得WebRTC对等端为自己活得一个可公开访问的地址，然后通过信令机制将其传递给另一个对等端以建立直接链接。（实际上不同NAT工作方式都有所不同，可能有多个NAT层，但是原理是一样的）。
因为 STUN服务器不需要做太多的工作或者记特别多的东西，所以相对低规格的 STUN服务器就可以处理大量的请求。
根据webrtcstats.com的统计（2013年），大多数WebRTC通话都成功地使用 STUN进行连接，有86%。尽管对于防火墙之后的对等端之间的呼叫以及复杂的NAT配置，成功通话量会更少一些。
WebRTC TURN协议初识及turnserver实践
2020-06-23 13:42:30
TURN的全称为Traversal Using Relays around NAT，是STUN/RFC5389的一个拓展，主要添加了Relay功能。如图一所示，TURN协议是建立在UDP协议之上的一个应用层协议。如果一台主机处于NAT后面，那么在一定条件下（NAT穿透失败）两台主机无法之间进行通讯。在这种条件下，那么使用中继服务提供通讯是有必要的。TURN协议允许一台主机使用中继服务与对端进行报文传输。TURN协议也是ICE（交互式连接建立）协议的组成部分，也可以单独使用。如果TURN使用于ICE协议中，relay地址会作为一个候选，由ICE在多个候选中进行评估，选取最合适的通讯地址。一般来说中继的优先级都是最低的。
TURN和其他中继协议的不同之处在于，它允许客户端使用同一个中继地址（relay address）与多个不同的peer进行通信。如图二所示。
搭建WebRtc环境
2020-06-23 13:34:14这次的需求，准备做的是一个类似与QQ视频一样的点对点视频聊天。这几天了解了一些知识后，决定使用HTML5新支持的WebRtc来作为视频通讯。客户端使用支持HTML5浏览器即可。服务器段需要提供两个主要的服务功能，一个是信令服务器(Signaling Server)，一个是NAT穿透服务器(ICE Server)。简单的框架图如下:
WebRTC搭建前端视频聊天室——信令篇
2020-06-23 13:31:44这篇文章讲述了WebRTC中所涉及的信令交换以及聊天室中的信令交换，主要内容来自WebRTC in the real world: STUN, TURN and signaling，我在这里提取出的一些信息，并添加了自己在开发时的一些想法。
WebRTC的服务器
WebRTC提供了浏览器到浏览器（点对点）之间的通信，但并不意味着WebRTC不需要服务器。暂且不说基于服务器的一些扩展业务，WebRTC至少有两件事必须要用到服务器：
1. 浏览器之间交换建立通信的元数据（信令）必须通过服务器
2. 为了穿越NAT和防火墙
为什么需要信令？
WebRTC搭建前端视频聊天室——数据通道篇
2020-06-23 13:29:17在两个浏览器中，为聊天、游戏、或是文件传输等需求发送信息是十分复杂的。通常情况下，我们需要建立一台服务器来转发数据，当然规模比较大的情况下，会扩展成多个数据中心。这种情况下很容易出现很高的延迟，同时难以保证数据的私密性。
这些问题可以通过WebRTC提供的RTCDataChannel API来解决，他能直接在点对点之间传输数据。这篇文章将介绍如何创建并使用数据通道，并提供了一些网络上常见的用例
为了充分理解这篇文章，你可能需要去了解一些RTCPeerConnection API的相关知识，以及STUN，TURN、信道如何工作。强烈推荐Getting Started With WebRTC这篇文章
webrtc 资源收集
2020-06-23 13:28:10webrtc 资源收集
短期爆发音视频需求背后的技术与发展趋势解读
2020-06-23 10:05:18特殊时期，音视频在短期内成为了很多人的“刚需”：在线学习、远程工作、联系亲友等众多场景下都离不开音视频技术。那么，音视频究竟是短期刚需还是未来趋势呢？3月5日采访间，为本次活动压轴专场线上公开直播，邀请到腾讯云视频通信业务总经理李郁韬、学而思网校架构师&腾讯云最具价值专家（TVP）刘连响作为嘉宾，LiveVideoStack联合创始人&主编包研作为主持人，深度剖析音视频技术发展。
文 / 李郁韬 刘连响 包研
整理 / LiveVideoStack
包研：欢迎大家来到「云加社区沙龙online」 采访间，我是LiveVideoStack主编包研，感谢云加社区的邀请，让我作为今天活动的主持人与大家互动。同时，今天我们也有幸邀请到了两位重磅嘉宾，分别是腾讯云视频通信业务总经理 李郁韬和学而思网校架构师 刘连响。
下面请两位先向观众做一个简单的自我介绍。
李郁韬：大家好，我是李郁韬，目前是腾讯云视频通信业务的负责人，很高兴能在云加社区与大家见面，这也是我人生第一次做直播，有些紧张。
刘连响：大家好，我是学而思网校架构师刘连响，目前主要负责RTC和直播相关的业务，最近几年的关注方向也主要集中在这些方面，包括推动WebRTC的大规模应用以及直播应用的探索。
包研：由于业务指数级暴增和大量的新业务对接，相信过去几周大家过的并不轻松，能否和大家分享下这段经历？
刘连响：我这边从春节到现在应该可以说是各种赶节奏，需要我们对多个项目进行同步支持，功能或者模块的开发时间被压缩的非常短，基本一到两天就要求交付。又因为是远程办公，所以处于全天工作的状态。印象比较深刻的是做小程序直播的时候，我们在晚上五六点钟立项，之后找到腾讯伙伴做小程序直播权限插件的升级、CDN的配置等工作，最后在第二天上午完成了上线，整个项目从立项到上线只花了十几个小时。
可能对于大多数国人来说，这个春节过得并不轻松，可以说是非常难忘的一个春节，李郁韬那边的情况想必也是一样。
开源流媒体服务器：为何一定得再撸个新的
2020-06-23 10:03:22作为开发者，我们需要有一个服务器来支持新视频行业的互联网化，有哪个开源方案能支持新爆发的业务？该方案需要支持哪些关键的能力或需求？本文由自阿里云RTC服务器团队负责人杨成立在LiveVideoStack线上分享的内容整理而成。
文 / 杨成立
整理 / LiveVideoStack
视频回放：
https://www2.tutormeetplus.com/v2/render/playback?mode=playback&token=7955f5f3e1c942fa9ae4314b991beb1c
大家好，我是来自阿里云的杨成立，本次分享将会和大家详细介绍开源流媒体服务器的关键技术及未来发展。
我从2009年开始从事FFmpeg流媒体相关工作，2012年开始参与流媒体服务器的开发，2013年开始做开源流媒体服务器SRS，至今也有七年多的时间了。在这短短几年间，随着视频直播的爆发，SRS也迎来了快速增长。2017年我来到阿里云之后换成了WebRTC方向。我们可以看到目前Live WebRTC在整个视频的应用非常广，包括在线办公、在线教育、在线娱乐等各个行业都大展拳脚，音视频已经成为当前互联网交流与信息传播不可或缺的媒介手段。
这次的分享内容将主要围绕SRS的诞生与历程、SRS接下来的发展计划等，带领大家深入研究SRS存在的价值与意义。
得益于我国通信基础设施的日趋完善，尤其是Wi-Fi、4G网络的下沉普及，我国互联网市场音视频产品服务在2015～2018年经历了爆发式增长。当时消费者普遍拥有的可以观看视频的带宽大约为1M，网络环境较为稳定。
直播背后的技术早在功能机时代就落地成熟。例如2010～2012年，消费者主要通过PC上的Flash来观看网络直播视频，因为Flash可以跨主流PC端浏览器。而移动端尽管也支持Flash，但效果很不好。移动端如Android或iOS则主要支持HLS，早期Android对HLS的支持效果并不佳，后面有明显改善。
webrtc笔记(3): 多人视频通讯常用架构Mesh/MCU/SFU
2020-06-23 09:25:40问题：为什么要搞这么多架构？
webrtc虽然是一项主要使用p2p的实时通讯技术，本应该是无中心化节点的，但是在一些大型多人通讯场景，如果都使用端对端直连，端上会遇到很带宽和性能的问题，所以就有了下图的三种架构。
