实现一个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中转

More...

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

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

事情是这样的。

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

More...

More...

实时传送协议（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的负载：

More...

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             |
|                             ....                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

More...

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

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

More...

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

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

More...

More...

前段时间上手了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 。这里假定你已经编译完成，输入

1. $ turnserver -h

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

More...

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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

More...

1、概述

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

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

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

More...

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

More...

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

More...

WebRTC协议栈

More...

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

More...

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

More...

众所周知，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]，本文只回顾其算法框架，并分析其在实际应用中存在的问题。

 

More...

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

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

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

More...

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

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

More...

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

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

More...

发起视频通话流程图如下

创建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";
}
}

More...

RTSP（实时流协议）

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

More...

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

More...

核心设计

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

More...

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），长度也是不固定的。

More...

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中的

More...