【WebRTC】术语

WebRTC，名称源自网页实时通信（英语：Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的API。它于2011年6月1日开源并在Google、Mozilla、Opera支持下被纳入万维网联盟的W3C推荐标准^[1][2][3]。

 

 

 

一、 NAT

　　NAT（Network Address Translation，网络地址转换）是1994年提出的。当在专用网内部的一些主机本来已经分配到了本地IP地址（即仅在本专用网内使用的专用地址），但现在又想和因特网上的主机通信（并不需要加密）时，可使用NAT方法。

这种方法需要在专用网连接到因特网的路由器上安装NAT软件。装有NAT软件的路由器叫做NAT路由器，它至少有一个有效的外部全球IP地址。这样，所有使用本地地址的主机在和外界通信时，都要在NAT路由器上将其本地地址转换成全球IP地址，才能和因特网连接。

另外，这种通过使用少量的公有IP 地址代表较多的私有IP 地址的方式，将有助于减缓可用的IP地址空间的枯竭。在RFC 1632中有对NAT的说明。

 

　　NAT不仅能解决了lP地址不足的问题，而且还能够有效地避免来自网络外部的攻击，隐藏并保护网络内部的计算机。

　　1.宽带分享：这是 NAT 主机的最大功能。

　　2.安全防护：NAT 之内的 PC 联机到 Internet 上面时，他所显示的 IP 是 NAT 主机的公共 IP，所以 Client 端的 PC 当然就具有一定程度的安全了，外界在进行 portscan（端口扫描） 的时候，就侦测不到源Client 端的 PC 。

 

二、

　　STUN（Session Traversal Utilities for NAT，NAT会话传输应用程序）是一种网络协议，它允许位于NAT（或多重NAT）后的客户端找出自己的公网地址，查出自己位于哪种类型的NAT之后以及NAT为某一个本地端口所绑定的Internet端端口。这些信息被用来在两个同时处于NAT 路由器之后的主机之间建立UDP通信。该协议由RFC 5389定义。

 

　　TURN（全名 Traversal Using Relay NAT），是一种资料传输协议（data-transfer protocol）。允许在TCP或UDP的连线上跨越 NAT 或防火墙。

　　TURN是一个client-server协议。TURN的NAT穿透方法与STUN类似，都是通过取得应用层中的公有地址达到NAT穿透。但实现TURN client的终端必须在通讯开始前与TURN server进行交互，并要求TURN server产生"relay port", 也就是relayed-transport-address。这时 TURN server会建立peer, 即远端端点（remote endpoints）, 开始进行中继（relay）的动作，TURN client利用relay port将资料传送至peer, 再由peer转传到另一方的TURN client。

 

三、ICE

　　面向对象中间件 (Internet Communications Engine)，是ZeroC开发的一个面向对象的中间件平台。它提供了面向对象的远程过程调用、网格计算和发布/订阅功能，并有基于GPL的双许可协议和一个私有许可协议。它支持Linux、Solaris、Windows和Mac OS X等最主要的操作系统，和C++、Java、.NET语言（如C#或Visual Basic）、Objective-C、Python、PHP和Ruby等语言^[1]。Ice运行时的一个轻量变体叫做Ice-e，^[2]可以运行在移动电话中。如它的名字所表明，该中间件可以被用于应用程序，而不需要使用HTTP协议，并且有能力穿越防火墙（这一点不同于当时的其它中间件）。

 

四、Talk

　　Talk协议能使远程计算机上的两个用户以实时方式进行通信。

 

五、VoIP

　　网际协议通话技术（Voice over Internet Protocol ）简而言之就是将模拟信号（Voice）数字化，以数据封包（Data Packet）的形式在IP网络(IP Network）上做实时传递。VoIP最大的优势是能广泛地采用Internet和全球IP互连的环境，提供比传统业务更多、更好的服务。VoIP可以在IP网络上便宜的传送语音、传真、视频、和数据等业务，如统一消息业务、虚拟电话、虚拟语音/传真邮箱、查号业务、Internet呼叫中心、Internet呼叫管理、电话视频会议、电子商务、传真存储转发和各种信息的存储转发等。

 

 

六、RTP

　　实时传输协议（Real-time Transport Protocol）是一个网络传输协议，它是由IETF的多媒体传输工作小组1996年在RFC 1889中公布的。

　　国际电信联盟ITU-T也发布了自己的RTP文档，作为H.225.0，但是后来当IETF发布了关于它的稳定的标准RFC后就被取消了。它作为因特网标准在RFC 3550（该文档的旧版本是RFC 1889）有详细说明。RFC 3551（STD 65，旧版本是RFC 1890）详细描述了使用最小控制的音频和视频会议。

　　RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。它一开始被设计为一个多播协议，但后来被用在很多单播应用中。RTP协议常用于流媒体系统（配合RTSP协议），视频会议和一键通（Push to Talk）系统（配合H.323或SIP），使它成为IP电话产业的技术基础。RTP协议和RTP控制协议RTCP一起使用，而且它是建立在UDP协议上的。

七、RTCP

　　实时传输控制协议（Real-time Transport Control Protocol或RTP Control Protocol）是实时传输协议（RTP）的一个姐妹协议。RTCP由RFC 3550定义（取代作废的RFC 1889）。RTP 使用一个 偶数 UDP port ；而RTCP 则使用 RTP 的下一个 port，也就是一个奇数 port。

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

　　RTCP收集相关媒体连接的统计信息，例如：传输字节数，传输分组数，丢失分组数，jitter，单向和双向网络延迟等等，网络应用程序即可利用RTCP的统计信息来控制传输的品质，比如当网络带宽高负载时限制信息流量或改用压缩比较小的编解码器。

　　RTCP本身不提供数据加密或身份认证。SRTCP可以用于此类用途。

八、RTSP

　　即时串流协定（Real Time Streaming Protocol）是用来控制声音或影像的多媒体串流协议，并允许同时多个串流需求控制，传输时所用的网络通讯协定并不在其定义的范围内，服务器端可以自行选择使用TCP或UDP来传送串流内容，它的语法和运作跟HTTP 1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。而前面提到的允许同时多个串流需求控制（Multicast），除了可以降低服务器端的网络用量，更进而支持多方视讯会议（Video Conference）。

九、RTMP

　　实时消息传输协议，（Real Time Messaging Protocol）。该协议基于TCP，是一个协议簇，包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种。RTMP是一种设计用来进行实时数据通信的网络协议，主要用来在Flash/AIR平台和支持RTMP协议的流媒体/交互服务器之间进行音视频和数据通信。支持该协议的软件包括Adobe Media Server/Ultrant Media Server/red5等。

十、XMPP

　　（Extensible Messaging and Presence Protocol，前称Jabber）是一种以XML为基础的开放式实时通信协议，是经由互联网工程工作小组（IETF）通过的互联网标准。XMPP因为被Google Talk应用而被广大网民所接触。

　　XMPP是一种基于标准通用标记语言的子集XML的协议，它继承了在XML环境中灵活的发展性。因此，基于XMPP的应用具有超强的可扩展性。经过扩展以后的XMPP可以通过发送扩展的信息来处理用户的需求，以及在XMPP的顶端建立如内容发布系统和基于地址的服务等应用程序。而且，XMPP包含了针对服务器端的软件协议，使之能与另一个进行通话，这使得开发者更容易建立客户应用程序或给一个配好系统添加功能。

　　Jabber是一个开放源代码形式组织产生的网络实时通信协议。XMPP原本是为即时通讯而量身定制，但由于XML Stanza本身是XML元素，在基于XML灵活发展的特性下，使得XMPP也可以适用其他方面，已经得到了IETF的批准。XMPP与IMPP、PRIM、SIP（SIMPLE）合称四大IM协议主流，在此4大协议中，XMPP是最灵活的。

十二、Jingle

　　Jingle 是XMPP的扩展协议。通过 Jingle 可以实现点对点（P2P）的多媒体交互会话控制，如：语音交互（VOIP），Jingle 由 Google 和 XMPP 基金会设计。

　　Jingle是XMPP的延伸。它添加了P2P会话控制（通信），以实现如同VoIP或视频会议的多媒体交互。

　　Jingle由Google及XMPP标准基金会设计。其多媒体流被设计用于RTP（实时传输协议）。若需要，可由NAT穿透辅助以使用ICE（交互式连接创建）。

在2009年12月，推荐的Jingle规范仍未被XMPP标准基金会通过，不过现已存在草案标准。由Google实现于Google Talk的libjingle程序库以BSD许可证发布。它同时实现了现行标准协议及前标准版本。

十三、G.711  G.722

G.711  G.722是G系列的语音编码中宽带的编码方式。

G.711

　　由国际电信联盟（ITU-T）制定的音频编码方式，又称为ITU-T G.711。

　　它是国际电信联盟ITU-T订定出来的一套语音压缩标准，它代表了对数PCM（logarithmic pulse-code modulation）抽样标准，主要用于电话。它主要用脉冲编码调制对音频采样，采样率为8k每秒。它利用一个 64Kbps 未压缩通道传输语音讯号。 起压缩率为1：2， 即把16位数据压缩成8位。是主流的波形声音编解码器。

G.722

　　1988年由国际电信联盟（ITU-T）订定音频编码方式，又称为ITU-T G.722，是第一个用于16KHz采样率的宽带语音编码算法。

　　G.722是支持比特率为64, 56和48kbps多频率语音编码算法。在G.722中，语音信号的取样率为每秒16000个样本。与3.6kHz的频率语音编码相比较，G.722可以处理频率达7kHz音频信号宽带。G.722 编码器是基于子带自适应差分脉冲编码（SB-ADPCM）原理的。信号被分为两个子带，并且采用 ADPCM 技术对两个子带的样本进行编码。

区别

　　G.722相对于G.711 采样频率由8KHZ扩展为16KHZ，语音质量得以提高。将信号划分为2个子带（高频，低频），每个子带中的信号都采用ADPCM（adaptive differential pulse code modulation）进行编码，ADPCM原理即只采样声音样本中增量变化的那一段。

　　在最后比特率的计算中，低频部分被分配到比较多的资源 8Kbps X 6bit， 高频部分被分配到比较少的资源（多为摩擦声，噪音等辅助音）8Kbps X 2bit。两者相加为64Kbps，故G.722相对于G.711比特率都为64kbps，但提高了语音质量。

　　在cisco CM7.0以上版本中已支持G.722编码算法，cisco 79以上系列交换机已将G.722编码作为默认首选编码。

 

G711 G723 G729线路占多少带宽问题

带宽=包长度×每秒包数

　　=包长度×（1/打包周期）

　　=（Ethernet头+IP头+UDP头+RTP头+有效载荷）×（1/打包周期）

　　=（208bit +160bit+64bit+96bit +有效载荷）×（1/打包周期）

　　=（528bit+（打包周期(秒)×每秒的比特数））×（1/打包周期）

　　=（ 528 / 打包周期 ) + 每秒比特数

按照上面的计算公式：

　　G711：20ms打包，带宽为 ( 528/20 + 64) Kbit/s=90.4 Kbit/s

　　G729：20ms打包，带宽为 ( 528/20 + 8 ) Kbit/s= 34.4 Kbit/s

　　G723：5.3k，30ms打包，带宽为 ( 528/30 + 5.3 ) Kbit/s=22.9 Kbit/s

　　业界一般按照下表提供的IP网带宽系数和以太网带宽系数来设计网络带宽：

编解码技术	压缩速率（Kbps）	打包周期（ms）	IP网带宽系数	以太网带宽系数
G.711 a/u	64	20	1.25	1.41
G.729 a/b	8	20	0.38	0.54
G.723.1(5.3kbit/s)	5.3	30	0.27	0.37
G.723.1(6.3Kbit/s)	6.3	30	0.25	0.36
H.263(384Kbit/s)	≈384	10	6	6.2

　　注：采用某种编码方式时，用64K乘以相应的带宽系数就可以得出其实际占用的带宽。当然如果是中继接口，还需要考虑信令占据一定的带宽，一般按照2.5%来计算。如果看不懂上面的计算方法,只需记住以下结果:

　　G711　　 实际占用带宽 每线90.4kbit/s 　　100线并发占用 9Mbps

　　G729 　　实际占用带宽 每线34.4kbit/s 　　100线并发占用 3.4Mbps

　　G723 　　实际占用带宽 每线22.9kbit/s　　 100线并发占用 2.2Mbps

ACK

资料传输确认 (acknowledgement)，用于确认资料有无正确的传输到接收端，在ASCII中编号为6

即确认字符，在数据通信中，接收站发给发送站的一种传输类控制字符。表示发来的数据已确认接收无误。

在TCP/IP协议中，如果接收方成功的接收到数据，那么会回复一个ACK数据。通常ACK信号有自己固定的格式,长度大小,由接收方回复给发送方。其格式取决于采取的网络协议。当发送方接收到ACK信号时，就可以发送下一个数据。如果发送方没有收到信号，那么发送方可能会重发当前的数据包，也可能停止传送数据。具体情况取决于所采用的网络协议。

TCP报文格式中的控制位由6个标志比特构成，其中一个就是ACK，ACK为1表示确认号有效，为0表示报文中不包含确认信息，忽略确认号字段。

 

ACK/NACK = 应答/非应答