[webrtc] 交互式连接建立（ICE）
2019-12-06 14:19:12
WebRtc中ICE原理
2019-12-06 14:17:29webRTC支持点对点通讯，但是webRTC仍然需要服务端：
. 协调通讯过程中客户端之间需要交换元数据，
如一个客户端找到另一个客户端以及通知另一个客户端开始通讯。
. 需要处理NAT（网络地址转换）或防火墙，这是公网上通讯首要处理的问题。
所以我们需要了解服务端相关的知识：信令、Stun、trun、ice。
一、什么是信令
信令就是协调通讯的过程，为了建立一个webRTC的通讯过程，客户端需要交换如下信息：
. 会话控制信息，用来开始和结束通话，即开始视频、结束视频这些操作指令。
. 处理错误的消息。
. 元数据，如各自的音视频解码方式、带宽。
. 网络数据，对方的公网IP、端口、内网IP及端口。
WebRTC 开发（二）源码下载与编译
2019-12-06 13:56:17在使用任何工具之前，我们都有必要对工具做大概地的了解，做到粗犷但不失偏颇，这对我们选择工具和切入点是很关键的。本节的标题虽然是 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年初移动端上出现了主播与观众之间可以通过实时视频聊天这种方式来沟通，即，视频连麦。那我们想实现这种视频连麦的功能该怎么做呢？
P2P网络技术-NAT的由来、类型以及优缺点
2019-12-06 13:54:29本文将讲述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技术之成功，影响之深远。
WebRTC中的RTP、SRTP、RTCP协议
2019-12-06 13:53:41本文将讲述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系列协议。
SDP协议详解
2019-12-06 13:52:45本文将介绍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描叙符包括：
- 会话名和目的
- 会话激活的时间区段
- 构成会话的媒体
- 接收这些媒体所需要的信息（地址，端口，格式）
- 会话所用的带宽信息
- 会话拥有者的联系信息
无需翻墙的 WebRTC 源码下载
2019-12-06 13:48:05关于 WebRTC 的源码下载和 Demo 的编译运行，WebRTC 的官方文档已经有非常详细的说明。以 Linux 为例，过程大概是这样的：
- 下载并安装 depot_tools。这是 WebRTC 的代码下载及编译工具集，下载即是把源码 clone 下来，所谓安装只是把 depot_tools 的目录路径放进系统的环境变量 PATH 中即可。
-
准备目录
12$ mkdir webrtc$ cd webrtc -
下载代码
12$ fetch --nohooks webrtc$ gclient sync -
安装依赖。
-
编译运行。
安装依赖和编译运行具体可以参考 WebRTC 的官方文档。
webrtc所有平台下载编译步骤详细说明
2019-12-06 13:47:201、安装depot tools
Windows：
国外下载：https://storage.googleapis.com/chrome-infra/depot_tools.zip
下载完把压缩包解压，然后把解压目录加入PATH环境变量
Linux（Android）/Mac（IOS）：
安装git
国外：git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
国内：git clone https://source.codeaurora.org/quic/lc/chromium/tools/depot_tools
把depot_tools目录加入
PATH：export PATH=`pwd`/depot_tools:"$PATH"基于Licode的WebRTC全球分布式架构
2019-12-05 11:50:52大家好，我是来自百家云的陈聪，今天我将为大家带来与Licode的WebRTC全球分布式架构相关的技术分享。之所以想为大家介绍这个架构，是因为我在使用WebRTC开源服务器时发现WebRTC并没有提供类似于分布式或集群的整体解决方案，希望百家云在此领域的探索能为大家带来有价值的帮助。
1. SFU
1.1 SFU简介
Agora SOLO X™：兼容 WebRTC 标准的抗丢包语音编码器
2019-12-05 11:48:57本文分享了声网Agora 首席音频工匠高泽华在 RTC 2018 实时互联网大会上，以《SOLO X™：兼容 WebRTC 标准的抗丢包语音编码器》为题的演讲。主要介绍了声网推出的抗丢包语音编码器 Agora SOLO™ 的算法特点，以及第二代编解码器 Agora SOLO X™ 的新特性与测试效果。以下为演讲实录。
去年，我们在 RTC 大会上分享了自主研发的抗丢包编解码方案 Agora SOLO™ ，主要是面向抗丢包网络，解决实时通信传输 last mile 的问题。
关于Agora SOLO™
有时，大家对丢包问题会有一些误解。很多人认为随着 4G 的普及和 5G 的建设，是不是丢包问题变得不重要了？我认为并不是这样，因为在现有网络条件下，不论是 server 到 server，还是 sever 到 last mile 都存在着大量的丢包问题。
我们谈到丢包就涉及到丢包的概念，到底什么叫做丢包？其实任何没有按时到达的包都是丢包。如果把一个包的延时拉到足够大，一般来说，我们可以通过无数次重传来解决丢包问题。如果这个包没有在规定的时间到达，都算丢包。而且，丢包也不一定是网络原因导致，有时候是由于系统的调度等原因造成。
举个例子。通常，Android 系统上播放线程、解码线程和收包线程都可以不是一个线程。Android 并不是特别实时的操作系统。一旦系统比较忙的时候，就容易产生收包线程和解码线程的冲突，导致丢包产生。而这种丢包是由于系统产生的。甚至在解码时，解码器完成解码后交给播放器播放，其中的 buffer 也会导致卡顿。
丢包也与带宽限制相关。如果带宽足够大，可以通过无数次重传来实现抗丢包效果。但如果带宽很有限，就不能完全依靠无限制的重传来实现抗丢包效果。
比如说，曾经联通做过这样的事情，流量包月，但每个月的带宽只能在 128kbps，满足你对网页和音视频的基本需求。在这种服务下，如果你开一些高性能或者大码率的信源通讯的时候就会产生带宽拥塞，带宽拥塞首先导致延时增加，下一步就会产生丢包。所以，实际上带宽和丢包也相关。
由于我们声网在全球布网，非洲、东南亚、中东和印度的网络状况与中国的网络状况相差还比较远。即使在中国的网络环境下，上海和偏远地区的网络状况也是不一样的。所以，并不是以后上了 5G 就不存在丢包问题了，相反，我认为随着网络的差异化会导致丢包的问题变得越来越普遍。