webrtc-RTPRTSPRTCP的概念

Real-time Transport Protocol)是用于Internet上针对多媒体数据流的一种传输层协议。RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。RTP协议常用于流媒体系统（配合RTCP协议），视频会议和一键通（Push to Talk）系统（配合H323或SIP），使它成为IP电话产业的技术基础。RTP协议和RTP控制协议RTCP一起使用，而且它是建立在UDP协议上的。

RTP 本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于低层服务去实现这一过程。 RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性。 RTP 实行有序传送， RTP 中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，例如：在视频解码中，就不需要顺序解码。

RTP 由两个紧密链接部分组成： RTP ― 传送具有实时属性的数据；RTP 控制协议（RTCP） ― 监控服务质量并传送正在进行的会话参与者的相关信息。

实时传输控制协议（Real-time Transport Control Protocol或RTP Control Protocol或简写RTCP）是实时传输协议（RTP）的一个姐妹协议。RTCP为RTP媒体流提供信道外（out-of-band）控制。RTCP本身并不传输数据，但和RTP一起协作将多媒体数据打包和发送。RTCP定期在流多媒体会话参加者之间传输控制数据。RTCP的主要功能是为RTP所提供的服务质量（Quality of Service）提供反馈。

RTCP收集相关媒体连接的统计信息，例如：传输字节数，传输分组数，丢失分组数，jitter，单向和双向网络延迟等等。网络应用程序可以利用RTCP所提供的信息试图提高服务质量，比如限制信息流量或改用压缩比较小的编解码器。RTCP本身不提供数据加密或身份认证。SRTCP可以用于此类用途。

安全实时传输协议（Secure Real-time Transport Protocol或SRTP）是在实时传输协议（Real-time Transport Protocol或RTP）基础上所定义的一个协议，旨在为单播和多播应用程序中的实时传输协议的数据提供加密、消息认证、完整性保证和重放保护。它是由David Oran（思科）和Rolf Blom（爱立信）开发的，并最早由IETF于2004年3月作为RFC 3711发布。

由于实时传输协议和可以被用来控制实时传输协议的会话的实时传输控制协议（RTP Control Protocol或RTCP）有着紧密的联系，安全实时传输协议同样也有一个伴生协议，它被称为安全实时传输控制协议（Secure RTCP或SRTCP）；安全实时传输控制协议为实时传输控制协议提供类似的与安全有关的特性，就像安全实时传输协议为实时传输协议提供的那些一样。

在使用实时传输协议或实时传输控制协议时，使不使用安全实时传输协议或安全实时传输控制协议是可选的；但即使使用了安全实时传输协议或安全实时传输控制协议，所有它们提供的特性（如加密和认证）也都是可选的，这些特性可以被独立地使用或禁用。唯一的例外是在使用安全实时传输控制协议时，必须要用到其消息认证特性。

RTSP（Real Time Streaming Protocol）是用来控制声音或影像的多媒体串流协议，并允许同时多个串流需求控制，传输时所用的网络通讯协定并不在其定义的范围内，服务器端可以自行选择使用TCP或UDP来传送串流内容，它的语法和运作跟HTTP 11类似，但并不特别强调时间同步，所以比较能容忍网络延迟。而前面提到的允许同时多个串流需求控制（Multicast），除了可以降低服务器端的网络用量，更进而支持多方视讯会议（Video Conference）。 因为与HTTP11的运作方式相似，所以代理服务器《Proxy》的快取功能《Cache》也同样适用于RTSP，并因RTSP具有重新导向功能，可视实际负载情况来转换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。

RTP：实时传输协议（Real-time Transport Protocol）

RTP/RTCP是实际传输数据的协议

RTP传输音频/视频数据，如果是PLAY，Server发送到Client端，如果是RECORD，可以由Client发送到Server

整个RTP协议由两个密切相关的部分组成：RTP数据协议和RTP控制协议（即RTCP）

RTSP：实时流协议（Real Time Streaming Protocol，RTSP）

RTSP的请求主要有DESCRIBE,SETUP,PLAY,PAUSE,TEARDOWN,OPTIONS等，顾名思义可以知道起对话和控制作用

RTSP的对话过程中SETUP可以确定RTP/RTCP使用的端口，PLAY/PAUSE/TEARDOWN可以开始或者停止RTP的发送，等等

RTCP：

RTP/RTCP是实际传输数据的协议

RTCP包括Sender Report和Receiver Report，用来进行音频/视频的同步以及其他用途，是一种控制协议

以下是每个协议的概要介绍：

一、RTP数据协议

RTP数据协议负责对流媒体数据进行封包并实现媒体流的实时传输，每一个RTP数据报都由头部（Header）和负载（Payload）两个部分组成，其中头部前12个字节的含义是固定的，而负载则可以是音频或者视频数据。

其中比较重要的几个域及其意义如下：

CSRC记数（CC）：表示CSRC标识的数目。CSRC标识紧跟在RTP固定头部之后，用来表示RTP数据报的来源，RTP协议允许在同一个会话中存在多个数据源，它们可以通过RTP混合器合并为一个数据源。例如，可以产生一个CSRC列表来表示一个电话会议，该会议通过一个RTP混合器将所有讲话者的语音数据组合为一个RTP数据源。

负载类型（PT）：标明RTP负载的格式，包括所采用的编码算法、采样频率、承载通道等。例如，类型2表明该RTP数据包中承载的是用ITU G721算法编码的语音数据，采样频率为8000Hz，并且采用单声道。

序列号：用来为接收方提供探测数据丢失的方法，但如何处理丢失的数据则是应用程序自己的事情，RTP协议本身并不负责数据的重传。

时间戳：记录了负载中第一个字节的采样时间，接收方能够时间戳能够确定数据的到达是否受到了延迟抖动的影响，但具体如何来补偿延迟抖动则是应用程序自己的事情。

从RTP数据报的格式不难看出，它包含了传输媒体的类型、格式、序列号、时间戳以及是否有附加数据等信息，这些都为实时的流媒体传输提供了相应的基础。RTP协议的目的是提供实时数据（如交互式的音频和视频）的端到端传输服务，因此在RTP中没有连接的概念，它可以建立在底层的面向连接或面向非连接的传输协议之上；RTP也不依赖于特别的网络地址格式，而仅仅只需要底层传输协议支持组帧（Framing）和分段（Segmentation）就足够了；另外RTP本身还不提供任何可靠性机制，这些都要由传输协议或者应用程序自己来保证。在典型的应用场合下，RTP一般是在传输协议之上作为应用程序的一部分加以实现的。

二、RTCP控制协议

RTCP控制协议需要与RTP数据协议一起配合使用，当应用程序启动一个RTP会话时将同时占用两个端口，分别供RTP和RTCP使用。RTP本身并不能为按序传输数据包提供可靠的保证，也不提供流量控制和拥塞控制，这些都由RTCP来负责完成。通常RTCP会采用与RTP相同的分发机制，向会话中的所有成员周期性地发送控制信息，应用程序通过接收这些数据，从中获取会话参与者的相关资料，以及网络状况、分组丢失概率等反馈信息，从而能够对服务质量进行控制或者对网络状况进行诊断。

RTCP协议的功能是通过不同的RTCP数据报来实现的，主要有如下几种类型：

SR：发送端报告，所谓发送端是指发出RTP数据报的应用程序或者终端，发送端同时也可以是接收端。

RR：接收端报告，所谓接收端是指仅接收但不发送RTP数据报的应用程序或者终端。

SDES：源描述，主要功能是作为会话成员有关标识信息的载体，如用户名、邮件地址、电话号码等，此外还具有向会话成员传达会话控制信息的功能。

BYE：通知离开，主要功能是指示某一个或者几个源不再有效，即通知会话中的其他成员自己将退出会话。

APP：由应用程序自己定义，解决了RTCP的扩展性问题，并且为协议的实现者提供了很大的灵活性。

RTCP数据报携带有服务质量监控的必要信息，能够对服务质量进行动态的调整，并能够对网络拥塞进行有效的控制。由于RTCP数据报采用的是多播方式，因此会话中的所有成员都可以通过RTCP数据报返回的控制信息，来了解其他参与者的当前情况。

在一个典型的应用场合下，发送媒体流的应用程序将周期性地产生发送端报告SR，该RTCP数据报含有不同媒体流间的同步信息，以及已经发送的数据报和字节的计数，接收端根据这些信息可以估计出实际的数据传输速率。另一方面，接收端会向所有已知的发送端发送接收端报告RR，该RTCP数据报含有已接收数据报的最大序列号、丢失的数据报数目、延时抖动和时间戳等重要信息，发送端应用根据这些信息可以估计出往返时延，并且可以根据数据报丢失概率和时延抖动情况动态调整发送速率，以改善网络拥塞状况，或者根据网络状况平滑地调整应用程序的服务质量。

三、RTSP实时流协议

作为一个应用层协议，RTSP提供了一个可供扩展的框架，它的意义在于使得实时流媒体数据的受控和点播变得可能。总的说来，RTSP是一个流媒体表示协议，主要用来控制具有实时特性的数据发送，但它本身并不传输数据，而是必须依赖于下层传输协议所提供的某些服务。RTSP可以对流媒体提供诸如播放、暂停、快进等操作，它负责定义具体的控制消息、操作方法、状态码等，此外还描述了与RTP间的交互操作（RFC2326）。

RTSP在制定时较多地参考了HTTP/11协议，甚至许多描述与HTTP/11完全相同。RTSP之所以特意使用与HTTP/11类似的语法和操作，在很大程度上是为了兼容现有的Web基础结构，正因如此，HTTP/11的扩展机制大都可以直接引入到RTSP中。

由RTSP控制的媒体流集合可以用表示描述（Presentation Description）来定义，所谓表示是指流媒体服务器提供给客户机的一个或者多个媒体流的集合，而表示描述则包含了一个表示中各个媒体流的相关信息，如数据编码/解码算法、网络地址、媒体流的内容等。

虽然RTSP服务器同样也使用标识符来区别每一流连接会话（Session），但RTSP连接并没有被绑定到传输层连接（如TCP等），也就是说在整个RTSP连接期间，RTSP用户可打开或者关闭多个对RTSP服务器的可靠传输连接以发出RTSP 请求。此外，RTSP连接也可以基于面向无连接的传输协议（如UDP等）。

检索媒体：允许用户通过HTTP或者其它方法向媒体服务器提交一个表示描述。如表示是组播的，则表示描述就包含用于该媒体流的组播地址和端口号；如果表示是单播的，为了安全在表示描述中应该只提供目的地址。

邀请加入：媒体服务器可以被邀请参加正在进行的会议，或者在表示中回放媒体，或者在表示中录制全部媒体或其子集，非常适合于分布式教学。

添加媒体：通知用户新加入的可利用媒体流，这对现场讲座来讲显得尤其有用。与HTTP/11类似，RTSP请求也可以交由代理、通道或者缓存来进行处理。

在CentOS 6版本，时间设置有date、hwclock命令，从CentOS 7开始，使用了一个新的命令timedatectl。

一、基本概念

11 GMT、UTC、CST、DST 时间

(1) UTC

整个地球分为二十四时区，每个时区都有自己的本地时间。在国际无线电通信场合，为了统一起见，使用一个统一的时间，称为通用协调时(UTC, Universal Time Coordinated)。

(2) GMT

格林威治标准时间 (Greenwich Mean Time)指位于英国伦敦郊区的皇家格林尼治天文台的标准时间，因为本初子午线被定义在通过那里的经线。(UTC与GMT时间基本相同，本文中不做区分)

(3) CST

中国标准时间 (China Standard Time)

代码如下:

GMT + 8 = UTC + 8 = CST

(4) DST

夏令时(Daylight Saving Time) 指在夏天太阳升起的比较早时，将时钟拨快一小时，以提早日光的使用。(中国不使用)

12 硬件时钟和系统时钟

(1) 硬件时钟

RTC(Real-Time Clock)或CMOS时钟，一般在主板上靠电池供电，服务器断电后也会继续运行。仅保存日期时间数值，无法保存时区和夏令时设置。

(2) 系统时钟

一般在服务器启动时复制RTC时间，之后独立运行，保存了时间、时区和夏令时设置。

二、timedatectl 命令

21 读取时间

   代码如下:

timedatectl //等同于 timedatectl status

22 设置时间

代码如下:

timedatectl set-time "YYYY-MM-DD HH:MM:SS"

23 列出所有时区

代码如下:

timedatectl list-timezones

24 设置时区

代码如下:

timedatectl set-timezone Asia/Shanghai

25 是否NTP服务器同步

代码如下:

timedatectl set-ntp yes //yes或者no

26 将硬件时钟调整为与本地时钟一致

代码如下:

timedatectl set-local-rtc 1

hwclock --systohc --localtime //与上面命令效果一致

注意 硬件时钟默认使用UTC时间，因为硬件时钟不能保存时区和夏令时调整，修改后就无法从硬件时钟中读取出准确标准时间，因此不建议修改。修改后系统会出现下面的警告。

   26 硬件时间设置成 UTC：

代码如下:

timedatectl set-local-rtc 1

hwclock --systohc --utc //与上面命令效果一致

webrtc中的带宽自适应算法分为两种：

1，　发端带宽控制，　原理是由rtcp中的丢包统计来动态的增加或减少带宽，在减少带宽时使用TFRC算法来增加平滑度。

2，　收端带宽估算，　原理是并由收到rtp数据，估出带宽；　用卡尔曼滤波，对每一帧的发送时间和接收时间进行分析，　从而得出网络带宽利用情况，修正估出的带宽。

两种算法相辅相成，　收端将估算的带宽发送给发端，　发端结合收到的带宽以及丢包率，调整发送的带宽。

下面具体分析两种算法：

2, 接收端带宽估算算法分析

结合文档http://toolsietforg/html/draft-alvestrand-rtcweb-congestion-02以及源码webrtc/modules/remote_bitrate_estimator/overuse_detectorcc进行分析

带宽估算模型： d(i) = dL(i) / c + w(i) d(i)两帧数据的网络传输时间差，dL(i)两帧数据的大小差， c为网络传输能力， w(i)是我们关注的重点， 它主要由三个因素决定：发送速率， 网络路由能力， 以及网络传输能力。w(i)符合高斯分布， 有如下结论：当w(i)增加是，占用过多带宽（over-using)；当w(i)减少时，占用较少带宽（under-using)；为0时，用到恰好的带宽。所以，只要我们能计算出w(i)，即能判断目前的网络使用情况，从而增加或减少发送的速率。

算法原理：即应用kalman-filters

theta_hat(i) = [1/C_hat(i) m_hat(i)]^T // i时间点的状态由C, m共同表示，theta_hat(i)即此时的估算值

z(i) = d(i) - h_bar(i)^T theta_hat(i-1) //d(i)为测试值，可以很容易计算出， 后面的可以认为是d(i-1)的估算值， 因此z(i)就是d(i)的偏差，即residual

theta_hat(i) = theta_hat(i-1) + z(i) k_bar(i) //好了，这个就是我们要的结果，关键是k值的选取，下面两个公式即是取k值的，具体推导见后继博文。

E(i-1) h_bar(i)

k_bar(i) = --------------------------------------------

var_v_hat + h_bar(i)^T E(i-1) h_bar(i)

E(i) = (I - K_bar(i) h_bar(i)^T) E(i-1) + Q(i) // h_bar(i)由帧的数据包大小算出

由此可见，我们只需要知道当前帧的长度，发送时间，接收时间以及前一帧的状态，就可以计算出网络使用情况。

接下来具体看一下代码：

[cpp] view

plaincopy

void OveruseDetector::UpdateKalman(int64_t t_delta,

double ts_delta,

uint32_t frame_size,

uint32_t prev_frame_size) {

const double min_frame_period = UpdateMinFramePeriod(ts_delta);

const double drift = CurrentDrift();

// Compensate for drift

const double t_ts_delta = t_delta - ts_delta / drift; //即d(i)

double fs_delta = static_cast<double>(frame_size) - prev_frame_size;

// Update the Kalman filter

const double scale_factor = min_frame_period / (10000 / 300);

E_[0][0] += process_noise_[0] scale_factor;

E_[1][1] += process_noise_[1] scale_factor;

if ((hypothesis_ == kBwOverusing && offset_ < prev_offset_) ||

(hypothesis_ == kBwUnderusing && offset_ > prev_offset_)) {

E_[1][1] += 10 process_noise_[1] scale_factor;

}

const double h[2] = {fs_delta, 10}; //即h_bar

const double Eh[2] = {E_[0][0]h[0] + E_[0][1]h[1],

E_[1][0]h[0] + E_[1][1]h[1]};

const double residual = t_ts_delta - slope_h[0] - offset_; //即z(i)， slope为1／C

const bool stable_state =

(BWE_MIN(num_of_deltas_, 60) fabsf(offset_) < threshold_);

// We try to filter out very late frames For instance periodic key

// frames doesn't fit the Gaussian model well

if (fabsf(residual) < 3 sqrt(var_noise_)) {

UpdateNoiseEstimate(residual, min_frame_period, stable_state);

} else {

UpdateNoiseEstimate(3 sqrt(var_noise_), min_frame_period, stable_state);

}

const double denom = var_noise_ + h[0]Eh[0] + h[1]Eh[1];

const double K[2] = {Eh[0] / denom,

Eh[1] / denom}; //即k_bar

const double IKh[2][2] = {{10 - K[0]h[0], -K[0]h[1]},

{-K[1]h[0], 10 - K[1]h[1]}};

const double e00 = E_[0][0];

const double e01 = E_[0][1];

// Update state

E_[0][0] = e00 IKh[0][0] + E_[1][0] IKh[0][1];

E_[0][1] = e01 IKh[0][0] + E_[1][1] IKh[0][1];

E_[1][0] = e00 IKh[1][0] + E_[1][0] IKh[1][1];

E_[1][1] = e01 IKh[1][0] + E_[1][1] IKh[1][1];

// Covariance matrix, must be positive semi-definite

assert(E_[0][0] + E_[1][1] >= 0 &&

E_[0][0] E_[1][1] - E_[0][1] E_[1][0] >= 0 &&

E_[0][0] >= 0);

slope_ = slope_ + K[0] residual; //1/C

prev_offset_ = offset_;

offset_ = offset_ + K[1] residual; //theta_hat(i)

Detect(ts_delta);

}

[cpp] view

plaincopy

BandwidthUsage OveruseDetector::Detect(double ts_delta) {

if (num_of_deltas_ < 2) {

return kBwNormal;

}

const double T = BWE_MIN(num_of_deltas_, 60) offset_; //即gamma_1

if (fabsf(T) > threshold_) {

if (offset_ > 0) {

if (time_over_using_ == -1) {

// Initialize the timer Assume that we've been

// over-using half of the time since the previous

// sample

time_over_using_ = ts_delta / 2;

} else {

// Increment timer

time_over_using_ += ts_delta;

}

over_use_counter_++;

if (time_over_using_ > kOverUsingTimeThreshold //kOverUsingTimeThreshold是gamma_2， gamama_3=1

&& over_use_counter_ > 1) {

if (offset_ >= prev_offset_) {

time_over_using_ = 0;

over_use_counter_ = 0;

hypothesis_ = kBwOverusing;

}

}

} else {

time_over_using_ = -1;

over_use_counter_ = 0;

hypothesis_ = kBwUnderusing;

}

} else {

time_over_using_ = -1;

over_use_counter_ = 0;

hypothesis_ = kBwNormal;

}

return hypothesis_;

}

android客户端和服务器端是基于IntentService的，具体如下：后台使用简单的servlet，支持GET或POST。这个servlet最终返回给前台一个字符串flag，值是true或false，表示登录是否成功。然后在安卓的ADT上创建一个安卓项目，建立两个Activity，分别作为登录界面和登录成功界面。HTTP的访问公共类，用于处理GET和POST请求。IntentService服务，用于在后台以队列方式处理耗时操作。在AndroidManifestxml中注册IntentService。注意uses-permission节点，为程序开启访问网络的权限。登陆界面处理，注意按钮监听事件中，使用Intent将要传递的值传给service。接收广播类中，同样使用Intent将要传递的值传给下一个Activity。在onCreate()中，动态注册接收广播类的实例receiver。在接收广播类中，不要使用完毕后忘记注销接收器，否则会报一个AreyoumissingacalltounregisterReceiver()的异常。

WebRTC（Web Real-Time Communication）也被称为网络实时通信，是由 Google、Mozilla 和其他公司推动的一个开源项目，它通过 Javascript API 实现无插件的实时通信，以及在不需要中介的情况下在浏览器之间交换任意数据。

WebRTC的优点：

WebRTC技术的诞生，有一个很重要的原因在于，在浏览器实现实时音视频通话，需要依赖相关插件或程序，而插件安全漏洞问题则更为关键。浏览器开发人员无法控制这些插件以及更新，因此插件带来的安全风险也相对较大。

在WebRTC诞生之前，开发实时音视频应用的成本是非常高，需要考虑的技术问题很多，如音视频的编解码，数据传输延时、丢包、网络抖动、回音处理和消除等，如果要兼容浏览器端的实时音视频通信，还需要额外安装插件。当然，可以考虑使用第三方成熟技术，比如当时世界顶级的互联网音视频方案GIPS(Global IP Solutions)，支付相应的费用就行。很多知名的应用或者软件服务商也都在用GIPS，如Yahoo，AOL，IBM，SKYPE，QQ等。

WebRTC项目的愿景：实时通信web化，让WebRTC成为互联网音视频实时通信的规范，让开发者基于此规范快速开发出安全、可靠的应用。未来的音视频实时通信，必定是现代化生产活动中极其重要的板块。以下是WebRTC的部分应用场景：

两个不同网络环境的（具备摄像头/麦克风多媒体设备的）客户端（浏览器或APP），要实现点对点的实时音视频对话，难点在哪里？

要实现P2P通信，首先需要了解彼此是否都支持相同的媒体能力，WebRTC默认使用V8编解码器，如果要连接的对方不支持V8解码，如果没有媒体协商过程。那么即使连接成功，把视频数据发给对方，对方也无法播放

比如：Peer-A端可支持VP8、H264多种编码格式，而Peer-B端支持VP9、H264，要保证二端都正确的编解码，最简单的办法就是取它们的交集H264

有一个专门的协议 ，称为Session Description Protocol (SDP)，可用于描述上述这类信息，在WebRTC中，参与视频通讯的双方必须先交换SDP信息，这样双方才能知根知底，而交换SDP的过程，也称为"媒体协商"。

交换数据会通过一个中间服务来完成，在这里，我们称之为信令服务器

在建立P2P连接时，需要交换的信息有：

最理想的场景

然而，在大多数情况下，两个对等端都是各自处于某个局域网之中，相互之间隔着NAT与防火墙

NAT(Network Address Translation)即为网路地址转换协议

局域网-->公网

公网-->局域网

可以借助STUN服务器，穿越NAT

在NAT四种主要类型中有三种是可以使用STUN穿透：完全圆锥型NAT、受限圆锥型NAT和端口受限圆锥型NAT。但大型公司网络中经常采用的对称型 NAT（又称为双向NAT）则不能使用STUN穿透，这类路由器会透过 NAT 布署所谓的「Symmetric NAT」限制。也就是说，路由器只会接受之前连线过的节点所建立的连线。

可以点对点连接的情况与需要中转的情况（数据来源于Google）

不过在国内大部分局域网无法穿越。

修改服务器管理员与来宾账户名，禁用来宾账户。

管理员账户使用复杂密码

开启防火墙，用到哪些端口，就开哪些。

打开漏洞更新，最好先更新好漏洞，再设置外网到服务器的通讯

在“本地安全设置”中加强设置，如：“用户权限”、“安全选项”等

有必要可以设置“本地安全设置”的“ip安全设置”

根据必要安装功能与软件，服务器安装的东西遵循越少越好

修改远程端口

优化系统，如关闭不用的共享

关闭不适用的服务，如：DHCP

启用SYN攻击保护（网上可找到具体操作）

清理系统垃圾

暂时只想到这么多，有些要根据具体情况具体分析。

WebRTC（Web Real-Time Communication）。Real-Time Communication，实时通讯。

WebRTC能让web应用和站点之间选择性地分享音视频流。在不安装其它应用和插件的情况下，完成点对点通信。

WebRTC背后的技术被实现为一个开放的Web标准，并在所有主要浏览器中均以常规JavaScript API的形式提供。对于客户端（例如Android和iOS），可以使用提供相同功能的库。 WebRTC是个 开源项目 ，得到Google，Apple，Microsoft和Mozilla等等公司的支持。2011年6月1日开源并在Google、Mozilla、Opera支持下被纳入万维网联盟的W3C推荐标准。

WebRTC包括一系列API和相互关联的协议来实现通信。

Voice over Internet Protocol，在网络上传输声音消息的技术。

例如网络音频通话。或者叫做IP电话，宽带电话。使用VoIP技术的一大原因是费用低。

Network address translation，网络地址转换。

NAT能给你的设备一个公共IP地址。一个路由器（router）有一个公共IP地址，每个连接到路由的设备有一个私有的IP地址。

设备发送请求时，会从一个特定端口，通过私有IP发送到路由的公共IP。这样每个设备在网上不需要都有一个公共IP地址，但也能被其它设备发现。

参考 IP Network Address Translator (NAT) Terminology and Considerations

Interactive Connectivity Establishment，互动式连接建立（交互式连通性建立）。

ICE是一套能让web浏览器之间互相连接的框架。通常来说，节点A到B是很难直接相连的。防火墙会阻止连接，设备没有公共IP地址，路由不允许直接连接其他节点。

ICE使用STUN或者TURN服务（或者同时使用两者）来建立连接。

参考 ICE | rfc8445

Session Traversal Utilities for NAT (STUN) ，NAT会话传输工具。

STUN协议能发现客户端（节点）的公共地址。客户端发送一个请求给网上的STUN服务器，服务器返回客户端的公共地址。不管客户端在路由器的NAT后能否可达。

STUN为请求者提供了可公开访问的IP地址，它就不再参与对话了。

有些路由器会限制设备与外面其它设备的连接。这意味着即使STUN服务器知道了路由的公共IP地址，也没法建立连接。

这种情况下我们需要使用 TURN 。

Traversal Using Relays around NAT，使用中继绕过NAT传输。

一些路由器使用一种叫“Symmetric NAT”（对称型NAT）的限制。这意味着路由器仅允许之前连接过的节点（peer）来建立连接。

STUN 提供了一个能让应用（终端，节点）穿过NAT的方法。STUN允许客户端获得一个传输地址（一个IP和端口）来获取其它节点的数据。

然而STUN获取到的地址不一定能被所有节点使用。这些地址是否可用取决于网络拓扑的情况。所以，单独STUN无法提供完整的穿越NAT的方案。

TURN协议允许两个处于NAT环境的主机利用中继进行通讯。客户端能够在TURN服务器上分配资源，与其它客户端（peer）进行通讯。

客户端关联一个TURN服务器的地址（relayed server address）来作为中继。

客户端发送报文给TURN服务，TURN服务使用relayed server address作为源地址向其他客户端中继转发报文。

穿越NAT，这个过程就像是“打洞”。也有人称TURN服务器为“打洞服务器”。

这么看，TURN服务器需要有大的带宽。因此，ICE会优先考虑直接通讯，无法直接通讯情况下会使用TURN。

参考 TURN rfc8656

Session Description Protocol，会话描述协议。

描述多媒体连接内容的协议。例如分辨率，格式，编码，加密算法等等。

实际上，SDP不是个真正的协议。它也是用来描述设备之间连接与传输多媒体的数据格式。

参考 SDP: Session Description Protocol | rfc8866

一些缩写

更多请参考 WebRTC概念简介