RR数据包从媒体流接收器发送到该媒体流的发送者。在SFU的情况下，RR由SFU产生，并发送到媒体流发送器，并且还从每个流接收器发送到SFU。(如图1)。
RR数据包内发送的反馈包括用于计算网络引入的往返时间延迟，抖动和信息丢失。
WebRTC SFU中发送数据包丢失反馈
2019-11-23 00:51:49多方WebRTC选择3：SFU
2019-11-23 00:50:32
多方WebRTC选择3的方案是SFU，它表示选择转发单元。SFU背后的想法与MCU相同。它在中间有一台媒体服务器，所有peers向它发送流，唯一不同的是，它不会做繁重的处理，服务器将其引到其它peers，这样它们可以进行任何所需的处理。
这样服务器不需要能支持那么繁重的处理运算，你可以利用MCU提供的好处，同时避免Mesh hassles和MCU的高代价。
SFU的结构如下图所示：
哪种TURN服务器正在被使用？
2019-11-23 00:48:19
为什么你的WebRTC产品需要TURN服务器
2019-11-23 00:46:47端到端通信的一个主要问题是，在许多情况下，这些端点并不在公共互联网中，而是位于网络（和端口）地址转换器（NAT）后面的专用地址空间中。随着互联网从DARPA项目发展成为全球范围的网络，很快就会明白IPv4的232地址空间早晚会用尽。
在20世纪90年代，开发了多种策略来延迟IPv4地址耗尽的时间，其中之一就是NAT的设计。NAT将端点的真实IP地址隐藏于世界其他地方，这使得端点之间建立端到端直接连接变得困难。这就是协助框架—包括STUN和TURN（或使用中继NAT穿越）—派上用场的地方。
平均约有30%的P2P会议有一个端点通过TURN服务器连接。如果没有TURN中继服务器的帮助，这些用户将无法进行通信。因此，开发者需要知道TURN服务器是什么，以及为什么它对WebRTC通话的重要性。
ICE和STUN
YouTube是如何使用WebRTC的
2019-11-23 00:45:51我周二登录了一次YouTube，注意到右上角有一个新的摄像头图标，并写着“Go Live（New）”，所以我点了一下它试试看会发生什么。事实证明，你现在可以直接从浏览器进行直播。这听起来真的很像WebRC，所以我加载了chrome://webrtc-internals来查看，并确定它就是WebRTC。我们总是对大规模部署很好奇，所以我立即请WebRTC逆向工程大师Philipp “Fippo” Hancke进行更深入的调查。本文剩下的部分就是他对此的分析。— 编辑：chad hart
WebRTC的NAT及防火墙简介（下）
2019-11-23 00:44:28NAT和点对点通讯：有何问题？
虽然客户端或服务器能够通过NAT /防火墙顺利连接，但这样的操作会对点对点通信造成严重破坏。点对点通信通常由端点应用程序打开，或用主机操作系统上的特定IP端口侦听。之后该端口可以与准备交换数据的另一台主机发信号或进行通信。应用程序中，点对点IP端口发出的指令通常用服务器或其他对等体发现机制来完成，与实际的点对点数据有所区分。示例如下：
WebRTC的NAT及防火墙简介（上）
2019-11-23 00:43:40什么是NAT？
NAT意为网络地址转换（https://en.wikipedia.org/wiki/Network_address_translation）。它是一种广泛使用的系统，多用于保留IPv4地址，或使本地网络管理员能够控制本地拓扑结构。实际上NAT技术多种多样，在此不多赘述。最常见的NAT设备通过改变通过它的数据包的IP报头信息得以运行。通常情况下NAT技术与防火墙结合完成，大多数家用路由器都如此，这些路由器通常在保证安全性的同时还保留了IPv4的地址空间，可谓一举两得。但正如我们所见，这也可能导致某些程序和协议出现问题，尤其是像WebRTC这样尝试进行点对点连接的。
常见的NAT 或者防火墙场景是私人或受保护的IP端点子网的场景，与公共互联网的环境不同。
WebRTC的规模会带来哪些挑战
2019-11-23 00:41:57
WebRTC直播流中，大规模所带来的挑战
1:1 != 1:1,000,000
只要是关于WebRTC的问题，规模有影响。
人们常常有这种想法，如果我能够运行一个1对1的视频通话，那么把它改进成一个三方视频通话也很简单。如果有了三方通话，那么距离四方通话也只有一步之遥了。假如我们已经到了四个人同时通话的地步，既然4和10之间没差多少，所以10个人通话肯定也是一样的。如果我们可以进行10人通话了，那么50人，甚至100人是不是也没问题了？
处理多用户之间的互动通话的做法放在实时广播方面也是正确的。
1对1的广播与1对100不同，当然与1比10,000与1比1,000,000也不同。
我需要一个媒体服务器来进行一对多的WebRTC广播吗？
2019-11-23 00:40:30一个字回答：要。
这是我这个星期经常被问到的问题。答案也很简单—是的，需要。
接着我收到了一个没有预料到的提问：
为什么需要？
这有点让我措手不及。倒不是因为我不知道答案。而是因为我不知道如何用简短的文字来回答他。我想这也不是一个简单的问题。
简单的答案是资源的限制，以及我们不控制大部分这些资源的事实。
基于路由表的webrtc流媒体服务器方案
2019-11-23 00:38:57概述
在开发流媒体服务器时，rtp数据如何在服务器之间转发，对于降低音视频延时和丢包有很重要的影响。
我设想了一种可以降低音视频延时的转发方案。思想来源于IP协议的路由表选路算法。
TCP UDP协议的区别
我们经常说tcp和udp的区别是，tcp是有连接的，udp是无连接的。