@TOC
什么WebRTC
WebRTC，名称源自网页即时通信（英语：Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的API。它于2011年6月1日开源并在Google、Mozilla、Opera支持下被纳入万维网联盟的W3C推荐标准。谷歌2011年6月3日宣布向开发人员开放WebRTC架构的源代码。这个源代码将根据没有专利费的BSD（伯克利软件发布）式的许可证向用户提供。开发人员可访问并获取WebRTC的源代码、规格说明和工具等。
WebRTC使用安全实时传输协议（Secure Real-time Transport Protocol，SRTP）对RTP数据进行加密，消息认证和完整性以及重播攻击保护。它是一个安全框架，通过加密RTP负载和支持原始认证来提供机密性。WebRTC的安全特性是其可靠性的重要组成部分，其基础全部围绕实时传输协议（Real-time Transport Protocol）进行。
详情参看：WebRTC
要学习WebRTC需要先理解一些基本概念
- 什么是实时传输协议？
实时传输协议（RTP）是专为多媒体电话（VoIP，视频会议，远程呈现系统），多媒体流（视频点播，直播）和多媒体广播而设计的网络协议。它最初由RFC1889中的IETF指定。RTC最初是为了协助IETF音频-视频传输工作组涉及寄给地理上分散的成员的视频会议而创建的。目前，RFC3550中指定的v2是过去15年中一直在使用的v2。
- RTP的设计基于应用层框架和集成层处理的基本原理。它提供源和负载类型标识，流同步，丢包和重新排序以及媒体流监控。
- RTP使用RTP控制协议（RTCP）报告媒体流的性能。
- 在这个过程中，媒体发送端发送封装在RTP中的编码媒体。它还发送RTCP发送端报告，这有助于不同媒体流的额播放同步。接收端维护一个抖动缓冲区，对媒体数据包进行重新排序，并根据数据包中编码的定时信息进行播放。如果数据包丢失，接收端进行数据包恢复或者隐藏错误。最后，在RTCP接收端报告中接收机粗略或详细地对统计数据进行报告，使媒体发送端能够调整其媒体编码速率，变成更好的编解码器或改变前向纠错量。
- RTP数据包报头格式
RTP包报头格式分为四个部分：同步源标识符（synchronization source identifier），贡献源标识符（contributing source identifier），时间戳（timestamp），序列号（sequence number），以及负载类型（payload type）。
- 同步源：同步源协助确定源端点。 当端点发送需要同步的多个媒体流时很有用。
- RTP时间戳：RTP时间戳有助于在适当的时间播放接收到的数据包，并从RTP数据包中重组媒体帧。
- RTP序列号：RTP序列号帮助识别丢失的数据包并且在数据包不按顺序到达的情况下重新排序数据包。
- 负载类型：负载类型描述了它所携带的媒体数据的编码。每个编解码器必须指定其相应的负载类型。
- RTCP报告
RTCP报告有三种：发送端报告，接收端报告和扩展报告。
- RTCP发送端报告
发送端使用RTCP发送端报告来帮助同步媒体流。为了实现这一点，它将各个媒体流的RTP时间戳与时钟时间相关联，并通知接收端当前的分组速率和比特率。- RTCP接收端报告
接收端测量输入流并在RTCP接收端报告中报告粗粒度的传输统计。此报告包括当前的丢包比例，接收到的最高序列号，并有助于计算往返时间。- RTCP扩展报告
RTCP扩展报告由端点用来描述复杂的度量标准，而不是RTCP接收端报告中所公开的。这包括相关的性能监控和拥塞控制指标，如抖动缓冲之后表，数据包延时变化，延时指标，丢弃数据包数量，体验质量等。新的度量标准也可以定义，只要它们涉及测量的内容，测量方式以及向其他端点报告的方式。
- RTP负载格式是什么样的？
定义负载格式需要识别媒体数据包的编码。这些编码可以是两种方式中的一种：编解码器专用的，例如H.264，H.263，H.261，MPEG-2，JPEG，G.711，G.722或AMR；通用的，例如前向纠错（FEC），NACK或多路复用流。
负载文件通常为媒体编解码器指定一个定义明确的数据包格式，并描述编解码器的两种规则：聚合规则（aggregation rules）和碎片规则（fragmentation rules）。聚合规则是为编解码器定义的，与IP最大传输单元（例如音频）相比，这些编解码器产生几个小帧。碎片规则是为产生大帧的编解码器定义的，例如视频编解码器的I帧。将大型帧分成较小的数据包而不依赖于IP碎片，主要是因为IP碎片数据包通常在网络中被丢弃，尤其是通过NAT或防火墙的时候。
- 什么是RTP报头扩展？
RTP报头扩展旨在传送独立于媒体的信息。 更具体地说，它们携带的数据通常可以适用于多种负载格式，并且需要比发送RTCP报告更频繁地进行报告。
例如，在为交互媒体发送NACK数据包时，每隔几十毫秒会产生双向媒体流和RTP数据包。在这种情况下，RTP报头扩展可以指示哪些序列号被正确接收或丢失。因此，他们不完全依赖RTCP接收端报告发送NACK或ACK。
使用报头扩展可能非常有用，因为它们向后兼容。不了解它们的端点可能会忽略它们。此外，它们是通用的，因为不需要为每个媒体编解码器重新定义相同的扩展名。
RTP报头扩展有多种用途，包括报告网络发送时间戳和媒体会议中跨多个流均衡客户端的音频级别。
- 什么是RTCP报告间隔？
使用RTP，通过发送RTP媒体数据包和接收RTCP反馈数据包创建一个闭环。RTCP反馈间隔通常是会话带宽的一小部分，不会影响媒体流量。RTCP报告间隔由会话中的同步源数量和会话带宽决定。
- 虽然会话带宽预计将在参与者之间进行分配，但实际上通常是预期同时活动的发送端的平均吞吐量的总和。例如，在音频会议中，会话带宽将是一个发送端的带宽。但是，对于视频会议，会话带宽取决于显示的用户数量。为了管理这个，会话带宽由会话管理层给出，因此为每个参与者计算相同的RTCP间隔值。
- 会话带宽的5%应该分配给控制流量。
- 在具有大量接收端和少量发送端的场景中，四分之一的报告带宽应由发送端平均分配，其余四分之三专用于接收端。这允许新的参与者快速从发件人报告接收CNAME和同步时间戳。对于新的参与者，RTCP时间间隔减半以快速声明他们的存在。
推荐的RTCP最小值为5秒。这适用于单向链路，或适用于不需要检测接收质量到的会话。- 减少的最小值是360除以会话带宽（以秒为单位）。它适用于单播双向多媒体会话的参与者，并适时发送反馈消息来执行拥塞控制或错误修复。
- 基于RTCP反馈的扩展RTP文件
在端点检测到数据包丢失或者通过报告间隔中途发生拥塞的情况下，RTCP报告不能提前发送，端点必须等待下一个计划的RTCP报告。这会导致媒体比特率不稳定和振荡。为了解决这个问题，端点实现了基于RTCP的反馈的扩展RTP配置文件。这是RTP默认时间规划的扩展，可以实现快速反馈。
通过此文件，只要报告间隔平均保持不变，端点就可以调整RTCP报告间隔，以便早于下一个计划的RTCP报告发送报告。此外，它还定义了一套错误恢复反馈消息，包括否定确认（NACK），图像丢失指示（PLI），切片丢失指示（SLI）和参考图像选择指示（RPSI）。
WebRTC 能做什么
- WebRTC实现了基于网页的视频会议，标准是WHATWG 协议，目的是通过浏览器提供简单的javascript就可以达到实时通讯（Real-Time Communications (RTC)）能力。
- WebRTC（Web Real-Time Communication）项目的最终目的主要是让Web开发者能够基于浏览器（Chrome\FireFox...）轻易快捷开发出丰富的实时多媒体应用，而无需下载安装任何插件，Web开发者也无需关注多媒体的数字信号处理过程，只需编写简单的Javascript程序即可实现，W3C等组织正在制定Javascript 标准API，目前是WebRTC 1.0版本，Draft状态；另外WebRTC还希望能够建立一个多互联网浏览器间健壮的实时通信的平台，形成开发者与浏览器厂商良好的生态环境。同时，Google也希望和致力于让WebRTC的技术成为HTML5标准之一，可见Google布局之深远。
- WebRTC提供了视频会议的核心技术，包括音视频的采集、编解码、网络传输、显示等功能，并且还支持跨平台：windows，linux，mac，android。
WebRTC 架构组件简介
1. Your Web App
Web开发者开发的程序，Web开发者可以基于集成WebRTC的浏览器提供的web API开发基于视频、音频的实时通信应用。
2. Web API
面向第三方开发者的WebRTC标准API（Javascript），使开发者能够容易地开发出类似于网络视频聊天的web应用。这些API可分成Network Stream API、 RTCPeerConnection、Peer-to-peer Data API三类。
Network Stream API
MediaStream：MediaStream用来表示一个媒体数据流。
MediaStreamTrack在浏览器中表示一个媒体源。
RTCPeerConnection
RTCPeerConnection: 一个RTCPeerConnection对象允许用户在两个浏览器之间直接通讯。
RTCIceCandidate ：表示一个ICE协议的候选者。
RTCIceServer:表示一个ICE Server。
Peer-to-peer Data API
DataChannel:数据通道( DataChannel)接口表示一个在两个节点之间的双向的数据通道 。
3. WebRTC Native C++ API
本地C++ API层，使浏览器厂商容易实现WebRTC标准的Web API，抽象地对数字信号过程进行处理。
4.Transport / Session（传输/会话层）
会话层组件采用了libjingle库的部分组件实现，无须使用xmpp/jingle协议
- RTP Stack协议栈
Real Time Protocol - STUN/ICE
可以通过STUN和ICE组件来建立不同类型网络间的呼叫连接。 - Session Management
一个抽象的会话层，提供会话建立和管理功能。该层协议留给应用开发者自定义实现。
5.VoiceEngine
音频引擎是包含一系列音频多媒体处理的框架，包括从视频采集卡到网络传输端等整个解决方案。
PS：VoiceEngine是WebRTC极具价值的技术之一，是Google收购GIPS公司后开源的。在VoIP上，技术业界领先，后面的文章会详细了解
- iSAC
Internet Speech Audio Codec
针对VoIP和音频流的宽带和超宽带音频编解码器，是WebRTC音频引擎的默认的编解码器
采样频率：16khz，24khz，32khz；（默认为16khz）
自适应速率为10kbit/s ~ 52kbit/s；
自适应包大小：30~60ms；
算法延时：frame + 3ms - iLBC
Internet Low Bitrate Codec
VoIP音频流的窄带语音编解码器
采样频率：8khz；
20ms帧比特率为15.2kbps
30ms帧比特率为13.33kbps
标准由IETF RFC3951和RFC3952定义 - NetEQ for Voice
针对音频软件实现的语音信号处理元件
NetEQ算法：自适应抖动控制算法以及语音包丢失隐藏算法。使其能够快速且高解析度地适应不断变化的网络环境，确保音质优美且缓冲延迟最小。
是GIPS公司独步天下的技术，能够有效的处理由于网络抖动和语音包丢失时候对语音质量产生的影响。
PS：NetEQ 也是WebRTC中一个极具价值的技术，对于提高VoIP质量有明显效果，加以AEC\NR\AGC等模块集成使用，效果更好。 - Acoustic Echo Canceler (AEC)
回声消除器是一个基于软件的信号处理元件，能实时的去除mic采集到的回声。 - Noise Reduction (NR)
噪声抑制也是一个基于软件的信号处理元件，用于消除与相关VoIP的某些类型的背景噪声（嘶嘶声，风扇噪音等等… …）
6.VideoEngine
WebRTC视频处理引擎
VideoEngine是包含一系列视频处理的整体框架，从摄像头采集视频到视频信息网络传输再到视频显示整个完整过程的解决方案。
- VP8
视频图像编解码器，是WebRTC视频引擎的默认的编解码器
VP8适合实时通信应用场景，因为它主要是针对低延时而设计的编解码器。
PS:VPx编解码器是Google收购ON2公司后开源的，VPx现在是WebM项目的一部分，而WebM项目是Google致力于推动的HTML5标准之一 - Video Jitter Buffer
视频抖动缓冲器，可以降低由于视频抖动和视频信息包丢失带来的不良影响。 - Image enhancements
图像质量增强模块
对网络摄像头采集到的图像进行处理，包括明暗度检测、颜色增强、降噪处理等功能，用来提升视频质量。
7.视频
WebRTC的视频部分，包含采集、编解码(I420/VP8)、加密、媒体文件、图像处理、显示、网络传输与流控(RTP/RTCP)等功能。
- 视频采集---video_capture
源代码在webrtc\modules\video_capture\main目录下，包含接口和各个平台的源代码。
在windows平台上，WebRTC采用的是dshow技术，来实现枚举视频的设备信息和视频数据的采集，这意味着可以支持大多数的视频采集设备；对那些需要单独驱动程序的视频采集卡（比如海康高清卡）就无能为力了。
视频采集支持多种媒体类型，比如I420、YUY2、RGB、UYUY等，并可以进行帧大小和帧率控制。 - 视频编解码---video_coding
源代码在webrtc\modules\video_coding目录下。
WebRTC采用I420/VP8编解码技术。VP8是google收购ON2后的开源实现，并且也用在WebM项目中。VP8能以更少的数据提供更高质量的视频，特别适合视频会议这样的需求。
视频加密--video_engine_encryption
视频加密是WebRTC的video_engine一部分，相当于视频应用层面的功能，给点对点的视频双方提供了数据上的安全保证，可以防止在Web上视频数据的泄漏。
视频加密在发送端和接收端进行加解密视频数据，密钥由视频双方协商，代价是会影响视频数据处理的性能；也可以不使用视频加密功能，这样在性能上会好些。
视频加密的数据源可能是原始的数据流，也可能是编码后的数据流。估计是编码后的数据流，这样加密代价会小一些，需要进一步研究。 - 视频媒体文件--media_file
源代码在webrtc\modules\media_file目录下。
该功能是可以用本地文件作为视频源，有点类似虚拟摄像头的功能；支持的格式有Avi。
另外，WebRTC还可以录制音视频到本地文件，比较实用的功能。
视频图像处理--video_processing
源代码在webrtc\modules\video_processing目录下。
视频图像处理针对每一帧的图像进行处理，包括明暗度检测、颜色增强、降噪处理等功能，用来提升视频质量。 - 视频显示--video_render
源代码在webrtc\modules\video_render目录下。
在windows平台，WebRTC采用direct3d9和directdraw的方式来显示视频，只能这样，必须这样。 - 网络传输与流控
对于网络视频来讲，数据的传输与控制是核心价值。WebRTC采用的是成熟的RTP/RTCP技术。
8.音频
WebRTC的音频部分，包含设备、编解码(iLIBC/iSAC/G722/PCM16/RED/AVT、NetEQ)、加密、声音文件、声音处理、声音输出、音量控制、音视频同步、网络传输与流控(RTP/RTCP)等功能。
- 音频设备---audio_device
源代码在webrtc\modules\audio_device\main目录下，包含接口和各个平台的源代码。
在windows平台上，WebRTC采用的是Windows Core Audio和Windows Wave技术来管理音频设备，还提供了一个混音管理器。
利用音频设备，可以实现声音输出，音量控制等功能。 - 音频编解码---audio_coding
源代码在webrtc\modules\audio_coding目录下。
WebRTC采用iLIBC/iSAC/G722/PCM16/RED/AVT编解码技术。
WebRTC还提供NetEQ功能---抖动缓冲器及丢包补偿模块，能够提高音质，并把延迟减至最小。
另外一个核心功能是基于语音会议的混音处理。
声音加密--voice_engine_encryption
和视频一样，WebRTC也提供声音加密功能。 - 声音文件
该功能是可以用本地文件作为音频源，支持的格式有Pcm和Wav。
同样，WebRTC也可以录制音频到本地文件。 - 声音处理--audio_processing
源代码在webrtc\modules\audio_processing目录下。
声音处理针对音频数据进行处理，包括回声消除(AEC)、AECM(AEC Mobile)、自动增益(AGC)、降噪(NS)、静音检测(VAD)处理等功能，用来提升声音质量。 - 网络传输与流控
和视频一样，WebRTC采用的是成熟的RTP/RTCP技术。
WebRTC 支持的浏览器
WebRTC在以下浏览器版本中开始支持。
- 桌上PC端
Google Chrome23
Mozilla Firefox22
Opera18
Safari11（仍处于开发者预览阶段） - Android端
Google Chrome 28（从版本29开始默认开启）
Mozilla Firefox 24
Opera Mobile 12 - IOS端
iOS 11 - 其他平台
Google Chrome OS
Firefox OS
Blackberry 10 内置浏览器
WebRTC 学习资料
WebRTC入门
1. WebRTC架构
1.1 基本的三角形WebRTC架构
在这个架构中，移动电话用“浏览器M”表示，笔记本电脑用“浏览器L”表示，通过Web服务器将它们连接起来。要建立一个实时媒体通讯，两台设备需要了解彼此的媒体功能，通过交换呼叫信令控制协议实现。
诸如这样的信令协议在WebRTC标准中并非事先规定，而是由开发者自行制定。在浏览器RTC会话的步骤如下：
- 首先，两个浏览器都从Web服务器下载了WebRTC程序（HTML5/JavaScript）；
- 其次，两个浏览器通过Web服务器交换控制信令信息（使用嵌入式信令服务器），建立媒体功能功能互通。
- 最后，两个浏览器直接建立RTC媒体的音频、视频和数据通道。
1.2 真正实用的基于P2P的WebRTC架构
WebRTC使用P2P媒体流，音频、视频和数据的连接直接通过浏览器实现。但是，浏览器却隐藏在NAT（网络地址翻译）和防火墙的后面，这增加了建立P2P媒体会话的难度。这些流程和协议，如ICE或Trickle ICE，STUN和TURN，在建立P2P媒体流都是必不可少的。
如何使用STUN协议建立一个P2P RTC媒体（如图5所示），简化版的ICE流程如下：
- 两个浏览器通过自己的公网IP地址，使用STUN协议信息和STUN服务器建立联系；
- 两个浏览器通过SDP提供/应答机制，使用呼叫控制信令消息交换它们已发现的公共IP地址（ICE候选）；
- 两个浏览器执行连接检查（ICE冲孔），确保P2P可以连接；
- 建立连接后，RTC媒体会话和媒体交换就可以实现了。
- 但是，假如在一个高度限制的NAT或防火墙，这种直接的路径将无法建立，只能到达TURN服务器。结果是媒体通过TURN服务器分程传递（如下图所示）。
2. WebRTC协议栈
参考资料：
