实现一个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连接建立过程，需要掌握几个知识点： NAT, ICE, STUN, TURN, DTLS等。如果之前有接触过P2P相关技术的同学可能就会比较容易理解。WebRTC是一个基于浏览器与浏览器之间的实时音视频通话方案，那么有于公网ip地址有限的问题，用户的浏览器常常位于NAT后，那么建立连接就涉及到了打洞技术。

NAT
由于当前使用的IPV4地址的长度限制只有32位，大多数终端都没有一个可以在互联网上可见的唯一IPV4地址。NAT是作为一种解决IPv4地址短缺以避免保留IP地址困难的方案，在IP数据包通过路由器或防火墙时重写来源IP地址或目的IP地址。

STUN
为了进行P2P通信，会话参与双方都需要知道其对等端的IP地址和指定的UDP端口。因此，在WebRTC通信建立之前，需要进行一定数量的信息交换。
每个对等端需要使用一个STUN服务器来探测他们的公共IP地址，这个IP在连接建立的时候会被ICE框架所引用。STUN服务器是通常是可公开访问的，WebRTC应用可以自由访问。

TURN
TURN服务指的是中继型NAT遍历服务器，其地址是一个公共ip地址，用于转发数据包给对端浏览器。当2个对等端因为NAT类型而无法建立连接时(当遇到对称型NAT会导致打洞失败)，才需要使用中继服务器。

ICE: 交互式连接建立（Interactive Connectivity Establishment）
ICE是一种标准穿透协议，利用STUN和TURN服务器来帮助端点建立连接。WebRTC当通过信令server交换完sdp, candidate后，之后依靠ICE框架在2端之间建立一个通道。

ICE的过程主要分为5步：

More...

WEBRTC ICE 简介
在这里，我会介绍一下WEBRTC 中， ICE 的机制。主要分为三个部分。

第一部分，为ICE的协议部分介绍。
第二部分，为STUN 的信令连接图。
第二部分，为WEBRTC中代码的实现流程。

More...

More...

webRTC支持点对点通讯，但是webRTC仍然需要服务端：
 . 协调通讯过程中客户端之间需要交换元数据，
   如一个客户端找到另一个客户端以及通知另一个客户端开始通讯。
 . 需要处理NAT（网络地址转换）或防火墙，这是公网上通讯首要处理的问题。
   所以我们需要了解服务端相关的知识：信令、Stun、trun、ice。

一、什么是信令
信令就是协调通讯的过程，为了建立一个webRTC的通讯过程，客户端需要交换如下信息：
 . 会话控制信息，用来开始和结束通话，即开始视频、结束视频这些操作指令。
 . 处理错误的消息。
 . 元数据，如各自的音视频解码方式、带宽。
 . 网络数据，对方的公网IP、端口、内网IP及端口。

More...

在使用任何工具之前，我们都有必要对工具做大概地的了解，做到粗犷但不失偏颇，这对我们选择工具和切入点是很关键的。本节的标题虽然是 WebRTC 源码下载与编译，但在这之前，我们有必要大概地了解 WebRTC，比如开发机构、免费性、支持的平台、功能亮点。

WebRTC 是一个免费开源的跨平台项目，由 Google，Mozilla，Opera 等支持，支持 Chrome，Firefox，Opera 以及 Android 和 iOS 平台，能够给浏览器、手机应用和物联网设备提供了实时互动能力。

WebRTC 是一组协议和 API。WebRTC 的起源可追溯到 2011年，经过六年多的时间的发展，在 2017年底 WebRTC 1.0 标准正式出炉。通过 WebRTC 的 Release Notes 可以看到现在最新的 release 版本是 M74 Release Noted。

2015年移动端直播的兴起，观众可以在手机端实时看主播的直播，但是观众与主播之间的沟通需要通过发弹幕来进行，这种交流的实时性较差，沟通不便利，观众参与感较差。2016年初移动端上出现了主播与观众之间可以通过实时视频聊天这种方式来沟通，即，视频连麦。那我们想实现这种视频连麦的功能该怎么做呢？

More...

本文将讲述WebRTC中使用的P2P技术，重点讲解NAT的由来、类型及优缺点。

##一、 IPV4协议和NAT的由来 IPv4即网际网协议第4版——Internet Protocol Version 4的缩写。IPv4定义了一个跨越异种网络互连的超级网，并为每个网际网的节点分配全球唯一的IP地址。如果把Internet比作一个邮政系统，那么IP地址的作用就等同于包含国家、城市、街区、门牌编号在内的完整地址。IP地址使用32bits整数表达一个地址，地址最大范围是2的32次方，约为43亿。在IP创始时期可被联网的设备来看，这样的一个空间很大，很难被短时间用完。然而，事实远远超出人们的设想，计算机网络在此后几十年迅速壮大，网络中断数量呈爆炸性增长。

更糟糕的是，为了路由和管理方便，43亿地址空间按照不同前缀长度分为A、B、C、D四类网络地址和保留地址。其中，A类网络地址127段，每段包括主机地址约1678万个。B类网络地址16384端，每段包括65536个主机地址。  IP地址管理机构IANA向超大型企业/组织分配A类网络地址，一次一段。向中型企业或者教育机构分配B类网络地址，一次一段。这种分配策略使得IP地址浪费极为严重，很多被分配的地址并未被真实利用，地址消耗很快。二十世纪90年代初，网络专家们意识到这样分配下去，IPv4地址很快就会耗光。于是人们开始考虑IPv4的替代方案，并采取一系列措施减缓IPv4的消耗。在这种背景下，NAT（网络地址转换）应运而生。

NAT是一项神奇的技术，它的出现几乎使IPv4起死回生。在IPv4已经被认为行将结束历史使命之后近20年时间里，人们几乎忘了IPv4的地址空间即将耗尽这样一个事实。更不用说，在NAT产生以后，网络终端的数量呈加速上升趋势，对IP地址的需求剧烈增加。此足见NAT技术之成功，影响之深远。

More...

本文将讲述WebRTC中RTP、SRTP、RTCP协议。本文内容来自于超越RFC3550 － RTP/RTCP协议族分析

##一、前言 RF3550定义了实时传输协议RTP和它的控制协议RTCP。RTP协议是Internet上针对实时流媒体传输的基础协议，该协议详细说明在互联网上传输音视频的标准数据包格式。RTP本身只保证实时数据的传输，并不能提供可靠传输、流量控制和拥塞控制等服务质量保证，这需要RTCP协议提供这些服务。

RTCP协议负责流媒体的传输质量保证，提供流量控制和拥塞控制等服务。在RTP会话期间，各参与者周期性彼此发送RTCP报文。报文中包含各参与者数据发送和接收等统计信息，参与者可以据此动态控制流媒体传输质量。RTP和RTCP配合使用，通过有效反馈使使流媒体传输效率最佳化。

IETF的RFC3550定义了RTP/RTCP协议的基本内容，包括报文格式、传输规则等。除此之外，IETF还定义一系列扩展协议，包括RTP扩展，RTCP报文类型扩展，等等。本文对这些协议进行初步归纳总结，在分析RFC3550的基础上，�重点分析RTP系列协议，并以报文类型为主线分析RTCP系列协议。

More...

本文将介绍WebRTC中的SDP协议，实际上SDP协议并不属于WebRTC专有协议。

一、SDP简述

ICE信息的描述格式通常采用标准的SDP,其全称为Session Description Protocol,即会话描述协议。SDP只是一种信息格式的描述标准,不属于传输协议,但是可以被其他传输协议用来交换必要的信息,如会话通知协议（SAP）、会话初始协议（SIP）、实时流协议（RTSP）、MIME 扩展协议的电子邮件以及超文本传输协议（HTTP）等。SDP协议是基于文本的协议，协议的可扩展性比较强，其具有广泛的应用范围。SDP 不支持会话内容或媒体编码的协商，所以在流媒体中只用来描述媒体信息。媒体协商这一块要用RTSP来实现。

流媒体协议sdp信息，附带在describe报文中有rtsp服务端发出，主要目的，告之会话的存在和给出参与该会话所必须的信息，sdp会话完全是文本形式，采用UTF-8编码的ISO 10646字符集。

图1-SDP协议例子  图2-SDP协议例子续 

sdp描叙符包括：

• 会话名和目的
• 会话激活的时间区段
• 构成会话的媒体
• 接收这些媒体所需要的信息（地址，端口，格式）
• 会话所用的带宽信息
• 会话拥有者的联系信息

More...

关于 WebRTC 的源码下载和 Demo 的编译运行，WebRTC 的官方文档已经有非常详细的说明。以 Linux 为例，过程大概是这样的：

1. 下载并安装 depot_tools。这是 WebRTC 的代码下载及编译工具集，下载即是把源码 clone 下来，所谓安装只是把 depot_tools 的目录路径放进系统的环境变量 PATH 中即可。

2. 准备目录

   1 2	$ mkdir webrtc $ cd webrtc

3. 下载代码

   1 2	$ fetch --nohooks webrtc $ gclient sync

4. 安装依赖。

5. 编译运行。

安装依赖和编译运行具体可以参考 WebRTC 的官方文档。

More...