WebRTC开发者社区为开发者提供最新最全的WebRTC资料

WebRTC下的网络连接: STUN, TURN, ICE, TCP

2019-11-26 11:01:38

实现一个WebRTC demo是比较容易的, 但如果要做一个webrtc产品, 则需要在任何网络环境下都能够建立网络连接.

Background: NAT

多数联网设备都位于局域网中, 并位于防火墙后面, 设备本身只有一个内网的私有IP, 在与外部通信时, 会经过1个或多个NAT路由器, 最终得到一个最外端的一个外部IP, 然后与远端目标机器通讯. 这一网络结构对于web应用, c/s型应用等来说不是问题, 但对于VoIP/P2P等应用就是一个问题了. 通信双方并不知道自己或对方的outermost的外网IP:Port, 如何建立直连呢?

这时就需要NAT穿透, 目前WebRTC采用的是ICE框架 (ICE+STUN+TURN), ICE也适用于非WebRTC应用, 这是目前业界用于穿透NAT的标准方案.

ICE使用了STUN, TURN等技术, 并扩展了SDP. ICE会同时尝试找出两个机器可行的连接方式, 并选择一个最高效的连接方式来穿透NAT. 参考文档:

RFC 5389 - STUN
RFC 5766 - TURN
RFC 5245 - ICE, updated by RFC 6336
RFC 6544 - TCP ICE
trickle ICE
SIP usage for trickle ICE
Tunneling WebRTC over TCP (and why it matters) - 介绍了STUN/TURN的作用
What kind of TURN server is being used?? - 提到了17.7%经过TURN中转

WebRTC 通话质量调优必备：三个弱网模拟测试工具

2019-11-28 10:12:16

作为一个使用 WebRTC 独立开发者或团队，怎样才能知道自己 App 的通话质量已经“达标”了呢？如何进行合理的弱网模拟测试？介绍给开发者们三个开源工具的部署、使用方法，及其各自优缺点。

如果你是长期关注 WebRTC 的资深开发者或技术爱好者，你可能留意到了，近期圈子里出了一个不大不小的话题，引得一些知名 WebRTC 技术博主纷纷发声，表明观点。

事情是这样的。

前不久，Jitsi 在其官方博客[1]上发布了一个 WebRTC 与 Zoom Web 客户端的视频通话对比测试。测试结果显示，WebRTC 的视频通话质量比 Zoom 还要好。一石激起千层浪，不少博主发表了自己的看法。

RFC5766-TURN协议

2019-11-28 10:32:19

摘要

如果一台主机处于NAT后面，那么在一定条件下两台主机无法之间进行通讯。在这种条件下，那么使用中继服务提供通讯是有必要的。
这个规范定义了一个名为TURN(使用中继穿越NAT)的协议，它允许一台主机使用中继服务与对端进行报文传输。TURN不同于其它中继协议在于它
允许客户机使用一个中继地址与多个对端同时进行通讯。
TURN协议也是ICE(交互式连接建立)协议的组成部分，也可以单独使用。

RTP格式解析

2019-12-05 03:38:37

实时传送协议（Real-time Transport Protocol或简写RTP，也可以写成RTTP）是一个网络传输协议，它是由IETF的多媒体传输工作小组1996年在RFC 1889中公布的。

RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。它一开始被设计为一个多播协议，但后来被用在很多单播应用中。RTP协议常用于流媒体系统（配合RTCP协议或者RTSP协议）。因为RTP自身具有Time stamp所以在ffmpeg 中被用做一种formate.

RTP协议格式：

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|X|  CC   |M|     PT      |       sequence number         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           timestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           synchronization source (SSRC) identifier            |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |            contributing source (CSRC) identifiers             |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
上图引自rfc3550，由上图中可知道RTP报文由两个部分构成--RTP报头和RTP的负载：

WebRTC之RTP包

2019-12-05 08:51:48

RTP固定头部

RTP的固定头部，详情可以阅读rfc文档5.1 RTP Fixed Header Fields

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|  CC   |M|     PT      |       sequence number         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           timestamp                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           synchronization source (SSRC) identifier            |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|            contributing source (CSRC) identifiers             |
|                             ....                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

WEBRTC 接收H264 RTP数据流小结

2019-12-05 08:53:12

这篇文章是对webrtc 中，接收H264 RTP包的一个总结，主要分为两个部分：

第一部分，介绍H264打包成RTP包的规范，以及WEBRTC中目前正在使用的几种格式。
第二部分，介绍WEBRTC的数据流，从接收RTP包，到拼装成H264 Frame，最终送入Decoder，获取YUV数据。

RFC5766-TURN协议

2019-12-06 15:06:14

如果一台主机处于NAT后面，那么在一定条件下两台主机无法之间进行通讯。在这种条件下，那么使用中继服务提供通讯是有必要的。
这个规范定义了一个名为TURN(使用中继穿越NAT)的协议，它允许一台主机使用中继服务与对端进行报文传输。TURN不同于其它中继协议在于它
允许客户机使用一个中继地址与多个对端同时进行通讯。

TURN协议也是ICE(交互式连接建立)协议的组成部分，也可以单独使用。

Stun详解与作用

2019-12-09 01:02:32

STUN是RFC3489规定的一种NAT穿透方式，它采用辅助的方法探测NAT的IP和端口。毫无疑问的，它对穿越早期的NAT起了巨大的作用，并且还将继续在NAT穿透中占有一席之地。

STUN的探测过程需要有一个公网IP的STUN server，在NAT后面的UAC必须和此server配合，互相之间发送若干个UDP数据包。UDP包中包含有UAC需要了解的信息，比如NAT外网IP，PORT等等。UAC通过是否得到这个UDP包和包中的数据判断自己的NAT类型。

假设有如下UAC（B），NAT（A），SERVER（C），UAC的IP为IPB，NAT的IP为 IPA ，SERVER的 IP为IPC1 、IPC2。请注意，服务器C有两个IP，后面你会理解为什么需要两个IP。

实战rfc5766-turn-server和ice4j广域网通讯

2019-12-06 15:49:22

前段时间上手了NAT打洞类库ice4j（ICE框架），当时使用了numb.viagenie.ca的公共STUN服务器。最近又编译了rfc5766-turn-server，于是今天将两者结合起来，一个作为服务端，一个作为Peer端的协议，试验广域网穿透多级路由即时点对点通讯，并取得了成功。

服务端

编译安装

rfc5766-turn-server是谷歌推荐的turn开源项目，经常作WebRTC的服务器端使用。关于rfc5766-turn-server在Windows或Ubuntu（Linux）下的编译，请参考 http://www.hankcs.com/program/network/compile-rfc5766-turn-server-to-build-turn-server.html 。这里假定你已经编译完成，输入

$ turnserver -h

得到如下结果说明编译成功：

Stun协议的格式记录

2019-12-09 01:03:13

Stun协议的格式，定义在https://www.ietf.org/rfc/rfc3489.txt

11.1  Message Header

   All STUN messages consist of a 20 byte header:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      STUN Message Type        |         Message Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                            Transaction ID
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

STUN--RFC5389摘要

2019-12-09 01:04:36

1、概述

RFC3489的劣势：一、NAT穿透有时会失败，但没有失败补救措施；二、NAT分类算法不适用于现代的很多NAT类型；三、安全弱点。

与RFC3489不同，该文档不再把STUN描述为解决NAT穿透的完整解决方案，而是将STUN作为一种工具集成到其他更完备的解决方案中去，例如本协议的扩展可用于ICE的两个端点之间的连接检测、用于TURN的的两个端点之间的包中转、用于SIP的客户端初始化连接。

该文档描述的STUN可运行在UDP、TLS/TCP、TCP上。

P2P通信标准协议(二)之TURN

2019-12-09 07:45:29

上一篇P2P通信标准协议(一)介绍了在NAT上进行端口绑定的通用规则，应用程序可以根据这个协议来设计网络以外的通信。

但是，STUN/RFC5389协议里能处理的也只有市面上大多数的Cone NAT（关于NAT类型可以参照P2P通信原理与实现），
对于Symmetric NAT，传统的P2P打洞方法是不适用的。因此为了保证通信能够建立，我们可以在没办法的情况下用保证成功的中继方法（Relaying），
虽然使用中继会对服务器负担加重，而且也算不上P2P，但是至少保证了最坏情况下信道的通畅，从而不至于受NAT类型的限制。TURN/RFC5766就是为此目的而进行的拓展。

P2P通信标准协议(一)之STUN

2019-12-09 07:46:04

前一段时间在P2P通信原理与实现中介绍了P2P打洞的基本原理和方法，我们可以根据其原理为自己的网络程序设计一套通信规则，
当然如果这套程序只有自己在使用是没什么问题的。可是在现实生活中，我们的程序往往还需要和第三方的协议（如SDP，SIP）进行对接，因此使用标准化
的通用规则来进行P2P链接建立是很有必要的。本文就来介绍一下当前主要应用于P2P通信的几个标准协议，主要有STUN/RFC3489，STUN/RFC5389，
TURN/RFC5766以及ICE/RFC5245。

WebRTC TURN协议初识及turnserver实践

2019-12-09 07:49:23

WebRTC协议栈

图一 WebRTC stack

P2P通信标准协议(三)之ICE

2019-12-09 08:04:21

在P2P通信标准协议(二)中,介绍了TURN的基本交互流程,在上篇结束部分也有说到,TURN作为STUN

协议的一个拓展,保持了STUN的工具性质,而不作为完整的NAT传输解决方案,只提供穿透NAT的功能,
并且由具体的应用程序来使用.虽然TURN也可以独立工作,但其本身就是被设计为ICE/RFC5245
的一部分,本章就来介绍一下ICE协议的具体内容.

P2P通信标准协议(四)之SIP

2019-12-09 08:05:08

在前面几篇文章中我们介绍了建立p2p通信的一般协议(簇),以及一种完整的NAT传输解决方案ICE,
但是对于多用户的通信情况,还有一些通用协议来实现标准化的管理,如之前讲过的SDP和SIP等,SIP(Session Initiation Protocol),
是属于应用层的控制协议,主要用于在一个或多个参与者之间创建,修改和中止会话(sessions).会话的类型包括IP电话,
多媒体流分发和多媒体会议等.

WebRTC基于TransportCC和Trendline Filter的发送端码率估计(Sendside-BWE)

2019-12-18 08:07:53

众所周知，WebRTC的拥塞控制和码率估计算法采用GCC算法[1]。该算法充分考虑了网络丢包和网络延迟对码率估计的不同影响，分别基于丢包率和网络延迟进行码率估计，最后综合这另种码率得出最优值。在算法实现上，基于丢包率的码率估计在发送端进行，基于网络延迟的码率估计在接收端进行。最后在发送端计算出最优值，作用于Codec和PacedSender模块。GCC算法能够较好地基于网络实时状况估计网络带宽，为网络实时通信应用打下坚实基础[2][3][4]。

然而，随着时间推移，在实际测试中发现GCC算法逐渐显出一些弊端，比如不能适应所有网络模型，应对网络峰值能力差，等等。为此，Google官方从M55版本引进最新的拥塞控制算法Sendside-BWE，把所有码率计算模块都移到发送端进行，并采用全新的Trendline滤波器取代之前的Kalman滤波器[5]。实测表明，新的算法实现能够更好更快地进行码率估计和网络过载恢复。

本文基于WebRTC的M66版本和相关RFC，深度分析学习最新Sendside-BWE算法的实现。

2 GCC算法回顾

关于GCC算法已经有很多分析和论述[6][7]，本文只回顾其算法框架，并分析其在实际应用中存在的问题。

webRTC是怎么应对网络变化的

2019-12-28 11:19:45

在视频通信的技术领域WebRTC已成为主流的技术标准，WebRTC包涵了诸多优秀的技术，譬如：音频数字信号处理技术（AEC, NS, AGC）、编解码技术、实时传输技术、P2P技术等，这些技术目的都是为了实现更好实时音视频方案。但是在高分辨率视频通信过程中，通信时延、图像质量下降和丢包卡顿是经常发生的事，甚至在WiFi环境下，一次视频重发的网络风暴可以引起WiFi网络间歇性中断，通信延迟和图像质量之间存在的排斥关系是实时视频过程中的主要矛盾。分析WebRTC是如何解决这个矛盾之前，先来看看我们在在线教育互动的生产环境统计到的视频延迟和人感官的关系，大致如下：

延迟感官描述
0 ~ 400毫秒人感觉不到视频在通信过程中的延迟
400 ~ 800毫秒人能感觉到轻微延迟，但不影响通信互动
800毫秒以上人能感觉到延迟而且影响通信互动。
也就是说，通信过程中最好将视频延迟控制在800毫秒以内。除了延迟，视频图像质量也是个对人感官产生差异的关键因素，我们以640x480分辨率每秒24帧的H264编码情况下视频码率和人感官之间的关系（这组数据是我们通过小范围线上用户投票打分的数据）：

码率感官描述
800kbps以上人对视频清晰度满意,感觉不到视频图像中的信息丢失
Phone 人对视频清晰度基本满意，有时能感觉到视频图像中的信息丢失
Pipe 人对视频清晰度不满意，大部分时候无法辨认图像中的细节信息
从上面的描述可以知道视频质量保持在一个可让人接受的质量范围是需要比较大的带宽码率支持的，如果加上控制延迟，则更需要网络有很好速度和稳定性。但是很不幸，我们现阶段的移动网络和家用WiFi并不是我们想象中的那么好，很难做到在实时视频通信中一个让人非常满意的程度。为了解决以上几个问题，WebRTC设计了一套基于延迟和丢包反馈的拥塞机制（GCC）和带宽调节策略来保证延迟、质量和网路速度之间平衡，这是一个持续循环过程，如下图：

Libjingle介绍

2019-12-28 12:13:08

国内现在很多语音聊天工具都是基于TURN方式实现的，包括YY、AK等等，这种方式对于服务器的性能要求很高，而且在用户量增大的时候，服务器压力也会越来越大，用户的语音质量也会受到很大影响。而基于P2P方式实现的语聊服务器，就可以极大的避免这种情况的发生，而且用户的语音体验也会非常好。

通过上文(P2P的原理和常见的实现方式(为libjingle开路))我们知道，因为NAT设备没有固定标准的原因，导致并不能100%的实现P2P，但是根据现在通用的ICE&STUN的方式，P2P的成功率可以达到90%多。前段时间在找使用这种方法实现的成熟库，最后猛然发现libjingle就在那里。
通过一个多星期的研究，在此记录一下libjingle库的大致情况，如有不妥，希望朋友们可以留言或者邮件(peakflys@gmail.com)指正。

WebRTC 学习笔记（2）--libjingle 部分（P2P传输）

2019-12-28 12:14:32

说明：此系类的内容都是本人自己对libjingle native API代码的学习总结。其中可能存在不准确甚至是错误的内容。欢迎大家帮忙指出错误。

此文是个人根据WebRTC项目中的libjingle部分总结出来。只代表WebRTC中的libjingle部分的结构，不代表原始的libjingle项目。

WebRtc libjingle_PeerConnection层（二） CreateOffer

2019-12-28 12:16:48

发起视频通话流程图如下

创建dsp描述符,CreateOffer在流程中位于 OnSignalingMessage(offer)

void CConductor::ConnectToPeer(int peer_id) {

if (peer_connection_.get()) {
LOG(LS_ERROR) <<
"We only support connecting to one peer at a time";
return;
}

if (InitializePeerConnection()) {
peer_connection_->CreateOffer(this, NULL);
}
else {
LOG(LS_ERROR) << "Failed to initialize PeerConnection";
}
}

RTSP/RTP/RTCP协议流程及分析

2019-12-30 02:41:46

RTSP（实时流协议）

RTSP中使用会话概念代替连接，由于它本身不与传输层绑定，因此RTSP会话在传输层支持TCP与UDP协议发送请求。RTSP客户机和服务器都可以发出请求，本身并不携带传输的媒体数据，而是控制RTP协议进行媒体数据传输。由于RTSP控制通过单独协议发送流，与控制通道无关，因此RTSP会话状态标记了服务器流资源的分配情况，如果对数据进行提取数据，需要同时进行流媒体数据传输协议（RTP协议）的解析。

WebRTC应用可能出现的网络错误

2020-05-29 10:16:07

为什么一个视频通话在某个环境下可以进行的很流畅，但是换了个网络环境就会变得很差？为什么一个音频通话一直在正常运行，却突然一下终端了呢？

WebRTC CDN 实现

2020-06-03 13:51:57

核心设计

把RTC技术与CDN架构融合，一套架构同时支持WebRTC和RTMP
支持一对一，多人互动场景
支持直播，大规模分发场景
架构保持足够简单，降低运维成本

P2P通信标准协议之STUN

2020-06-03 13:53:06

STUN简介

在前言里我们看到，RFC3489和RFC5389的名称都是STUN，但其全称是不同的。在RFC3489里，STUN的全称是Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)，即穿越NAT的简单UDP传输，是一个轻量级的协议，允许应用程序发现自己和公网之间的中间件类型，同时也能允许应用程序发现自己被NAT分配的公网IP。这个协议在2003年3月被提出，其介绍页面里说到已经被STUN/RFC5389所替代，后者才是我们要详细介绍的。

RFC5389中，STUN的全称为Session Traversal Utilities for NAT，即NAT环境下的会话传输工具，是一种处理NAT传输的协议，但主要作为一个工具来服务于其他协议。和STUN/RFC3489 类似，可以被终端用来发现其公网IP和端口，同时可以检测端点间的连接性，也可以作为一种保活（keep-alive）协议来维持NAT的绑定。和RFC3489最大的不同点在于，STUN本身不再是一个完整的NAT传输解决方案，而是在NAT传输环境中作为一个辅助的解决方法，同时也增加了TCP的支持。RFC5389废弃了RFC3489，因此后者通常称为classic STUN，但依旧是后向兼容的。而完整的NAT传输解决方案则使用STUN的工具性质，ICE就是一个基于offer/answer方法的完整NAT传输方案，如SIP。

STUN是一个C/S架构的协议，支持两种传输类型。一种是请求/响应（request/respond）类型，由客户端给服务器发送请求，并等待服务器返回响应；另一种是指示类型（indication transaction），由服务器或者客户端发送指示，另一方不产生响应。两种类型的传输都包含一个96位的随机数作为事务ID（transaction ID），对于请求/响应类型，事务ID允许客户端将响应和产生响应的请求连接起来；对于指示类型，事务ID通常作为debugging aid使用。

所有的STUN报文信息都含有一个固定头部，包含了方法，类和事务ID。方法表示是具体哪一种传输类型（两种传输类型又分了很多具体类型），STUN中只定义了一个方法，即binding（绑定），其他的方法可以由使用者自行拓展；Binding方法可以用于请求/响应类型和指示类型，用于前者时可以用来确定一个NAT给客户端分配的具体绑定，用于后者时可以保持绑定的激活状态。类表示报文类型是请求/成功响应/错误响应/指示。在固定头部之后是零个或者多个属性（attribute），长度也是不固定的。

Android WebRTC简介

2020-06-09 08:47:41

WebRTC名称源自网页实时通信(Web Real-Time Communication)的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的技术，是谷歌2010年以6820万美元收购Global IP Solutions公司而获得的一项技术。Google于2011年6月3日开源的即时通讯项目，旨在使其成为客户端视频通话的标准。其实在Google将WebRTC开源之前，微软和苹果各自的通讯产品已占用很大市场份额（如Skype），Google`也是为了快速扩大市场，所以将他给开源。在行业内得到了广泛的支持和应用，成为下一代视频通话的标准。更多介绍可以去官网上看。

WebRTC被誉为是web长期开源开发的一个新启元，是近年来Web开发的最重要创新。WebRTC允许Web开发者在其web应用中添加视频聊天或者点对点数据传输，不需要复杂的代码或者昂贵的配置。目前支持Chrome、Firefox和Opera，后续会支持更多的浏览器，它有能力达到数十亿的设备。

然而，WebRTC一直被误解为仅适合于浏览器。事实上，WebRTC最重要的一个特征是允许本地和web应用间的互操作，很少有人使用到这个特性。

本文主要以开源项目AndroidRTC为例。
下载后通过Android Studio打开，打开的时候可能会报错，说找不到org.json:json:20090211，这时只要将AndroidRTC/webrtc-client/build.gradle中的

如何实现1080P延迟低于500ms的实时超清直播传输技术

2021-06-23 00:20:35

最近由于公司业务关系，需要一个在公网上能实时互动超清视频的架构和技术方案。众所周知，视频直播用 CDN + RTMP 就可以满足绝大部分视频直播业务，我们也接触了和测试了几家 CDN 提供的方案，单人直播没有问题，一旦涉及到多人互动延迟非常大，无法进行正常的互动交谈。对于我们做在线教育的企业来说没有互动的直播是毫无意义的，所以我们决定自己来构建一个超清晰（1080P）实时视频的传输方案。

先来解释下什么是实时视频，实时视频就是视频图像从产生到消费完成整个过程人感觉不到延迟，只要符合这个要求的视频业务都可以称为实时视频。关于视频的实时性归纳为三个等级：

伪实时：视频消费延迟超过 3 秒，单向观看实时，通用架构是 CDN + RTMP + HLS，现在基本上所有的直播都是这类技术。
准实时：视频消费延迟 1 ~ 3 秒，能进行双方互动但互动有障碍。有些直播网站通过 TCP/UDP + FLV 已经实现了这类技术，YY 直播属于这类技术。
真实时：视频消费延迟 < 1秒，平均 500 毫秒。这类技术是真正的实时技术，人和人交谈没有明显延迟感。QQ、微信、Skype 和 WebRTC 等都已经实现了这类技术。

市面上大部分真实时视频都是 480P 或者 480P 以下的实时传输方案，用于在线教育和线上教学有一定困难，而且有时候流畅度是个很大的问题。在实现超清晰实时视频我们做了大量尝试性的研究和探索，在这里会把大部分细节分享出来。

WebRTC中丢包重传NACK实现分析

2021-06-28 09:40:29

在WebRTC中，前向纠错(FEC)和丢包重传(NACK)是抵抗网络错误的重要手段。FEC在发送端将数据包添加冗余纠错码，纠错码连同数据包一起发送到接收端；接收端根据纠错码对数据进行检查和纠正。RFC5109[1]定义FEC数据包的格式。NACK则在接收端检测到数据丢包后，发送NACK报文到发送端；发送端根据NACK报文中的序列号，在发送缓冲区找到对应的数据包，重新发送到接收端。NACK需要发送端发送缓冲区的支持，RFC5104[2]定义NACK数据包的格式。</br>

本文在研究WebRTC源代码的基础上，以Video数据包的发送和接收为例，深入分析ANCK丢包重传机制的实现。主要内容包括：SDP协商NACK，接收端丢包判定，NACK报文构造、发送、接收和解析，RTP数据包重传。下面分别详细论述之。</br>

WebRTC基于TransportCC和Trendline Filter的发送端码率估计(Sendside-BWE)

2021-06-28 09:41:16

众所周知，WebRTC的拥塞控制和码率估计算法采用GCC算法[1]。该算法充分考虑了网络丢包和网络延迟对码率估计的不同影响，分别基于丢包率和网络延迟进行码率估计，最后综合这另种码率得出最优值。在算法实现上，基于丢包率的码率估计在发送端进行，基于网络延迟的码率估计在接收端进行。最后在发送端计算出最优值，作用于Codec和PacedSender模块。GCC算法能够较好地基于网络实时状况估计网络带宽，为网络实时通信应用打下坚实基础[2][3][4]。

然而，随着时间推移，在实际测试中发现GCC算法逐渐显出一些弊端，比如不能适应所有网络模型，应对网络峰值能力差，等等。为此，Google官方从M55版本引进最新的拥塞控制算法Sendside-BWE，把所有码率计算模块都移到发送端进行，并采用全新的Trendline滤波器取代之前的Kalman滤波器[5]。实测表明，新的算法实现能够更好更快地进行码率估计和网络过载恢复。

本文基于WebRTC的M66版本和相关RFC，深度分析学习最新Sendside-BWE算法的实现。

webrtc QOS方法一（NACK实现）

2021-06-28 09:41:48

与NACK对应的是ACK，ACK是到达通知技术。以TCP为例，他可靠因为接收方在收到数据后会给发送方返回一个“已收到数据”的消息（ACK），告诉发送方“我已经收到了”，确保消息的可靠。

NACK也是一种通知技术，只是触发通知的条件刚好的ACK相反，在未收到消息时，通知发送方“我未收到消息”，即通知未达。

在rfc4585协议中定义可重传未到达数据的类型有二种：

1）RTPFB：rtp报文丢失重传。

2）PSFB：指定净荷重传，指定净荷重传里面又分如下三种：
1、PLI (Picture Loss Indication) 视频帧丢失重传。
2、SLI (Slice Loss Indication) slice丢失重转。
3、RPSI (Reference Picture Selection Indication)参考帧丢失重传。

在创建视频连接的SDP协议里面，会协商以上述哪种类型进行NACK重转。以webrtc为例，会协商两种NACK，一个rtp报文丢包重传的nack（nack后面不带参数，默认RTPFB）、PLI 视频帧丢失重传的nack。

webrtc的rtp重传代码分析

2021-06-28 23:29:13

pgm不太能用，没有想象中的可靠，重传机制貌似仍然使用组播重传，丢包率80%的网络感觉没啥改进，如果有所好转延迟估计也是个不小的问题。

后听说rtp也有nack机制，webrtc基于rtp实现了重传在一定程度上保证可靠性。

在各路大神的指引下找到了rfc4585，看到了这么一段 RTCP扩展反馈报文，有一种nack报文

webrtc源码之nack&&rtx详解

2021-06-28 23:30:30

video协商为h264(payload type=96)

从sdp可得到：

1）profile-level-id=42001f

Profile: 66(hex: 42)

Level: 3.1(hex:1f)转成十进制，再除以10

2）packetization-mode=1

表示I帧会拆分成多个rtp包发送，对于264来说，rtppayload的第一个字节（0x7C）的低5bit为(11100)，十进制为28，代表此nalutype为FU-A，多包封装类型。

3）RTP/AVPF

AVPF中的F表示支持RTCP的传输层保护，S表示安全保护（SRTP）

4) a=fmtp:97 apt=96

表示96类型的rtp包的重传包采用97的payloadtype的rtx包保护，rtx包的rtp header中的sequence num与rtp不一致，但timestamp一致。

Rtx包的payload的前两个字节为原重传rtp包的rtp sequencenum

2、webrtcpeerconnection_client项目修改项

webrtc QOS方法一（NACK实现）

2021-06-28 23:32:11

一、概念
与NACK对应的是ACK，ACK是到达通知技术。以TCP为例，他可靠因为接收方在收到数据后会给发送方返回一个“已收到数据”的消息（ACK），告诉发送方“我已经收到了”，确保消息的可靠。

NACK也是一种通知技术，只是触发通知的条件刚好的ACK相反，在未收到消息时，通知发送方“我未收到消息”，即通知未达。

在rfc4585协议中定义可重传未到达数据的类型有二种：

1）RTPFB：rtp报文丢失重传。

2）PSFB：指定净荷重传，指定净荷重传里面又分如下三种：
1、PLI (Picture Loss Indication) 视频帧丢失重传。
2、SLI (Slice Loss Indication) slice丢失重转。
3、RPSI (Reference Picture Selection Indication)参考帧丢失重传。

在创建视频连接的SDP协议里面，会协商以上述哪种类型进行NACK重转。以webrtc为例，会协商两种NACK，一个rtp报文丢包重传的nack（nack后面不带参数，默认RTPFB）、PLI 视频帧丢失重传的nack。

webrtc nack实现原理

2021-06-28 23:40:16

1.nack 简介
webrtc 中nack是最基本的QOS策略，与ack机制不同的地方是nack是接收端检测到丢包时，告知发送端具体丢包的序号，接收端收到nack后从缓存中找到对应的包并发送出去。

2. nack实现

nack rtcp报文格式如上图所示，pt=205。Packet identifier(PID) 为丢包起始参考值，Bitmap of Lost Packets(BLP)为16位的bitmap，对应为1的为表示丢包数据，具体如下抓包分析：

webrtc视频流程

2021-07-03 16:39:30

1. 创建视频引擎VideoEngine

函数：VideoEngine::Create()

构建VideoEngineImpl对象，该类继承了ViEBaseImpl、ViECodecImpl、ViECaptureImpl、
ViEFileImpl、ViEImageProcessImpl、ViENetworkImpl、ViERenderImpl、
ViERTP_RTCPImpl、ViEExternalCodecImpl、VideoEngine类，
同时ViEBaseImpl实例化视频共享数据单元ViEShareData，将该共享数据对象分发给各Impl类。

WebRTC之带宽控制部分学习(1) ------基本demo的介绍

2021-07-03 16:40:04

WebRTC的代码真是非常之大啊，下载以及编译了我好几天才搞完。。。。。

可以看到WebRTCd代码分成了4个部分，目前为止只看了talk里的一些东西。

1、 talk中的项目文件大多数都是以libjingle开头的，可以看出libjingle是WebRTC中非常核心的一个东西啦。

libjingle中开辟了两个通道，分别为会话通道和数据通道，一个用来会话建立管理等，一个用来传输数据。

libjingle_media是用来渲染获取视频，libjingle_p2p和libjingle_peerconnection是不同的会话方式用到的库吧，现在还没有细看

peerconnection_client和peerconnection_server则是可以直接运行的demo，设为启动项目就可以测试了，先运行server。

2、由于项目研究的是关于带宽估计的东西，所以我们看的文件主要有两个，一个是上行带宽的估计和控制，一个是下行带宽的估计和控制

上行带宽的文件在webrtc/modules/bitrate_controller，下行带宽的文件是remote_bitrate_estimator

下面讲一讲Goolge的WebRTC中自带的码率控制：

LearningWebRTC: 拥塞控制LearningWebRTC: 拥塞控制

2021-07-03 16:41:39

我不是拥塞控制专家，只懂皮毛，以后随着对WebRTC拥塞控制理解的加深，会进一步更新本文。

WebRTC 基于GCC的拥塞控制(下)

2021-07-03 16:43:17

本文在文章[1]的基础上，从源代码实现角度对WebRTC的GCC算法进行分析。主要内容包括： RTCP RR的数据源、报文构造和接收，接收端基于数据包到达延迟的码率估计，发送端码率的计算以及生效于目标模块。

拥塞控制是实时流媒体应用的重要服务质量保证。通过本文和文章[1][2]，从数学基础、算法步骤到实现细节，对WebRTC的拥塞控制GCC算法有一个全面深入的理解，为进一步学习WebRTC奠定良好基础。

1 GCC算法框架再学习

本节内容基本上是文章[1]第1节的复习，目的是再次复习GCC算法的主要框架，梳理其算法流程中的数据流和控制流，以此作为后续章节的行文提纲。GCC算法的数据流和控制流如图1所示。

图1 GCC算法数据流和控制流

对发送端来讲，GCC算法主要负责两件事：1)接收来自接收端的数据包信息反馈，包括来自RTCP RR报文的丢包率和来自RTCP REMB报文的接收端估计码率，综合本地的码率配置信息，计算得到目标码率A。2)把目标码率A生效于目标模块，包括PacedSender模块，RTPSender模块和ViEEncoder模块等。

WebRTC 基于GCC的拥塞控制(上)

2021-07-03 16:44:01

实时流媒体应用的最大特点是实时性，而延迟是实时性的最大敌人。从媒体收发端来讲，媒体数据的处理速度是造成延迟的重要原因；而从传输角度来讲，网络拥塞则是造成延迟的最主要原因。网络拥塞可能造成数据包丢失，也可能造成数据传输时间变长，延迟增大。

拥塞控制是实时流媒体应用质量保证(QoS)的重要手段之一，它在缓解网络拥堵、减小网络延迟、平滑数据传输等质量保证方面发挥重要作用。WebRTC通控制发送端数据发送码率来达到控制网络拥塞的目的，其采用谷歌提出的拥塞控制算法(Google Congestion Control，简称GCC[1])来控制发送端码率。

本文是关于WebRTC拥塞控制算法GCC的上半部分，主要集中于对算法的理论分析，力图对WebRTC的QoS有一个全面直观的认识。在下半部分，将深入WebRTC源代码内部，仔细分析GCC的实现细节。

1 GCC算法综述

P2P技术详解(三)：P2P技术之STUN、TURN、ICE详解(转载)

2021-07-06 13:18:39

内容概述

在现实Internet网络环境中，大多数计算机主机都位于防火墙或NAT之后，只有少部分主机能够直接接入Internet。很多时候，我们希望网络中的两台主机能够直接进行通信，即所谓的P2P通信，而不需要其他公共服务器的中转。由于主机可能位于防火墙或NAT之后，在进行P2P通信之前，我们需要进行检测以确认它们之间能否进行P2P通信以及如何通信。这种技术通常称为NAT穿透（NAT Traversal）。最常见的NAT穿透是基于UDP的技术，如RFC3489中定义的STUN协议。

STUN，首先在RFC3489中定义，作为一个完整的NAT穿透解决方案，英文全称是Simple Traversal of UDP Through NATs，即简单的用UDP穿透NAT。

在新的RFC5389修订中把STUN协议定位于为穿透NAT提供工具，而不是一个完整的解决方案，英文全称是Session Traversal Utilities for NAT，即NAT会话穿透效用。RFC5389与RFC3489除了名称变化外，最大的区别是支持TCP穿透。

TURN，首先在RFC5766中定义，英文全称是Traversal Using Relays around NAT:Relay Extensions to Session Traversal Utilities for NAT，即使用中继穿透NAT:STUN的扩展。简单的说，TURN与STURN的共同点都是通过修改应用层中的私网地址达到NAT穿透的效果，异同点是TURN是通过两方通讯的“中间人”方式实现穿透。

ICE跟STUN和TURN不一样，ICE不是一种协议，而是一个框架（Framework），它整合了STUN和TURN。

WebRTC PeerConnection 建立连接过程介绍

2021-07-06 13:23:12

0x00 前言
WebRTC 中数据传输都是通过被称为 PeerConnection 的对象来完成的，PeerConnection 在可以传输数据前的建立过程相对于传统的 C/S 模式有略微差别，类似于 P2P 连接的建立过程，并且复用了传统的 STUN/TURN/ICE 架构的 P2P 实现方式。由于 WebRTC 支持 MESH/SFU/MCU 三种模式，使用 PeerConnection 概念的好处是可以同时兼容这三种模式，即使是像 SFU/MCU 这种非 P2P 的场景也同样使用 PeerConnection 来建立传输通道，不过针对 SFU/MCU 场景已经有一些优化方案，例如 ice-lite 。本文介绍了 P2P 和 SFU 场景中 PeerConnection 建立的过程。

从janus中学习webrtc的ice简单交换过程

2021-07-06 14:22:30

1. 简介：

本文通过web和janus进行实时音视频通信的Demo，结合rfc-5245来学习ice交换的过程。

2. 测试模型

本文测试模型为一个NAT内的web的客户端，向一个NAT内的janus服务器发起请求。

3. rfc 5245

本文只捡基础的一个流程进行分析，5245协议本身囊括的内容较多。(这里主要围绕2, 2.1, 2.2三段)。

详解|SRT编码器中Rendezvous模式详解

2022-06-27 11:51:54

KILOVIEW最近发布SRT相关文章中，大家对caller模式和listener模式比较容易理解，近期收到很多客户反馈，对Rendezvous模式不是特别了解，下面将对Rendezvous模式进行详细介绍。

功能

两台设置Rendezvous模式的设备会共同协商，通过相同的UDP端口号建立一个SRT会话。

使用场景

两台设备所在的网络都有防火墙（或者路由器，功能等同），防火墙Outside接口是公网IP地址，但是没有防火墙的操作权限（即无法配置端口映射），如果防火墙设置了适当的工作模式，可通过Rendezvous模式建立SRT会话。

一旦完成SRT连接的建立，SRT源设备和SRT目标设备便开始交换控制信息，然后直接利用建立起来的SRT通道去传输数据。