流媒体 - webrtc基础知识点一

什么是WebRTC

WebRTC是一个免费的开放项目，通过简单的api为浏览器和移动应用程序提供实时通信(RTC)功能。WebRTC组件已经过优化，以最好地满足这一目的。

第一次接触

官方网站是学习webRTC很好的参考资料，Google I/O 2013 中关于WebRTC的视频以及关于WebRTC的ppt也给我们对webRTC的认识提供了一个概览。为了更加容易理解这些内容，首先我们需要了解相关的一些术语的概念。

WebRTC实时通讯基本术语

• NAT
  NAT(Network Address Translation)网络地址转换器是一种可以将我们的本地私有网络与公共互联网对应联系起来的盒子（物理意义上或者是虚拟的盒子）,可以理解为一个防火墙或者一个网关或者路由器。负责维护局域网IP地址和端口号与公共IP地址之间的映射表。当我们的手机在使用WIFI的情况下，IP地址一般是192.168.x.x这种局域网地址，这时可以说手机端在NAT后面，不是直接拥有公网地址。NAT主要的作用是将使用的内部IP地址（局域网地址）翻译成对应的公共IP地址（公网地址）。NAT实际上是（Network Address and Port Translator ）网络地址和端口转换器,因为大多数时候即时设备可同时更改传输地址和传输端口号。如何确定是否处于对称NAT后

• ICE
  交互式连通性建立（Interactive Connectivity Establishment — ICE）是一个允许实时对等端发现对方并且彼此连接的框架。WebRTC的目的是在网络浏览器之间建立端到端连接。由于端与端之间存在多层防火墙和NAT设备阻隔，因此我们需要一种机制来收集两端之间公共线路的IP，因此它使用了一系列的技术，统称为ICE。ICE允许位于特定类型的NAT路由器之后的终端可以建立直接连接。而位于NAT后面（局域网内）的终端实际上不知道自己的IP地址，不知道自己的公网IP地址，在建立连接的第一个问题就是需要找到自己对应的公网IP地址。此时需要依赖于STUN服务器和TURN服务器
  1.如果配置了STUN服务器，ICE代理会查询外部STUN服务器，以取得本地端的公共IP和端口
  2.如果配置了TURN服务器，ICE则会将TURN服务器作为一个候选项，当端到端的连接失败，数据将通过指定的中间设备转发。

• STUN服务器
  STUN(Session Traversal Utilitis for NAT)一种用于遍历NAT的,位于公网的具有公网IP的服务器。位于NAT后面的终端可以通过访问STUN服务器来获取终端所有的候选地址。前面说过，NAT可以将终端使用的内部IP地址翻译成对应的公共IP地址，当NAT后面的终端向STUN服务器发送消息（STUN测试数据包）时，会经过NAT(NAT穿透)，这时身处公网的STUN服务器就可以收集经过转换的网络信息如NAT的IP地址（这个地址就成为一个潜在的候选地址），然后发送给终端。这样终端就找到了自己对应的公网IP地址

• TURN
  一种用于帮助遍历NAT的服务器。当两个想建立连接进行音视频通信的网络环境都很复杂，都处于NAT后面且双方始终无法建立连接时，可通过查询TURN服务器的来获取中继地址（一个公共的IP地址），用于转发从终端收到的数据包，或者将收到的数据包转发给终端。比如用其帮忙转发音视频流。注意当两个对等端单纯的因为NAT的类型无法建立对等媒体会话（连接），则可依赖TURN服务器

• 候选地址（Candidates）
  对于将要进行建立会话的每个端，收集到可以通过Internet访问他们的IP地址和端口组及为候选地址。一个候选地址可理解为一组IP+端口号+优先级+网络类型组成的字符串。每个终端因网络环境不同可能有多个候选地址。如手机同时具有4G网络地址和WIFI分配的局域网地址

• 提议(OFFER) / 应答(ANSWER) 协商
  收集到可访问终端的候选地址后，要在双方之间建立媒体会话，必须在二者之间进行协商会话，用于为会话确定一组通用的功能特性。在WebRtc中使用的协商方式称为“提议/应答”。一方针对要建立的媒体会话类型创建描述，以此来发起媒体会话，此过程称为“提议”。另一方收到提议后予以回应，此过程称为应答。在WebRTC中使用RTCSessionDescription对象来表示提议和应答。即SDP。

• SDP
  SDP（Session Description Protocol）交换会话描述协议,主要是对WebRTC会话的描述。描述媒体信息和传输信息等。而在WebRTC API中对应编码为RTCSessionDescription对象。SDP用一组按照特定格式设置的数据来描述端到端连接的参数。SDP不包含媒体本身的任何信息，仅用于描述"会话状况"，表现为一系列的连接属性：要交换的媒体类型（音频、视频及应用数据）、网络传输协议、使用的编解码器及其设置、带宽及其他元数据。所以SDP主要用于对媒体会话的精细控制。

• RTP和SRTP
  RTP(Real-time Transport Protocol)是实时传输协议,SRTP(Secure RTP)是安全的实时传输协议，SRTP协议用于在webRTC客户端之间传输音频和视频媒体数据包，媒体数据包中包含由麦克风、摄像头、或应用程序生成的数字化音频帧或视频帧，并使用扬声器或显示器播放。
  SRTP提供为传输媒体所需要的必要信息：编解码器（用于对音频或视频进行采样和压缩的编码器/解码器）、媒体源（同步源或SSRC,标识数据包的发送方）、时间戳（用于确定播放时刻）、序列号（用于检测丢失的数据包）以及进行播放所需的其它信息。对于非音频或视频数据，将不再使用SRTP,而是调用RTCDataChannel API,这将在浏览器之间开通一个数据通道，以便交换任意格式的数据。

• SSRC（源标识符)
  比如一个音频流或一个视频流我们可以称为一个发送源，每个源都有一个唯一的标识，叫SSRC，比如一个客户端可以同时接收多路视频流，则也就有了多个SSRC，在一个链路通道中，我们是使用SSRC来区分每一个数据包是属于哪个视频源的。进而将此数据包解码后渲染在正确的窗口。

• WebRTC中的媒体
  一、轨道
  MediaStreamTrack是WebRTC中的基本媒体单元，此轨道代表一种设备或者录制内容（称为“源”）可返回的单一类型媒体。每个轨道都有一个源与之关联，通过WebRTC不能直接访问和控制源，对源的一切控制都通过轨道实施。轨道不仅可以来自源的原始媒体，还可能是浏览器提供的经过转换的版本。
  二、流
  MediaStream是MediaStreamTrack对象的集合。有两种方式可用于创建这些MediaStream对象：一是通过从现有MediaStream中复制轨道来请求对本地媒体的访问；二是使用对等连接接受新的流。请求和访问本地媒体的方式：通过getUserMedia()。

• WebRTC中的对等连接
  就WebTRC而言，对等连接指的是两个终端之间的直接媒体连接

• 信令 在WebRTC中，信令并没有标准化，即WebRTC没有提供交换SDP的方式，因此开发人员可以自行选择使用的信令协议（如SIP或Jingle）来传输SDP。 一、信令主要作用 1）协商媒体的功能和设置 信令的最主要功能，在参与对等连接的两个浏览器（终端）之间交换会话描述协议（Session Description Protocol,SDP）对象中包含的信息。包括，媒体类型（音频、视频、数据）、所用的编解码器（Opus、G.711等）、用于编解码器的各个参数或设置，以及有关宽带的信息。此外还有候选地址的交换（可选）。另外还有用于SRTP的秘钥材料

2）标识和验证会话参与者的身份 在使用标准信令协议（如SIP或者Jingle）发起实时通信时，信令通道将提供参与者的标识，并可以选择进行身份验证。

3）控制媒体会话、指示进度、更改会话和终止会话 在WebRTC中，需要信令才能发起或更改媒体会话，但不需要信令来指示状态或终止会话，浏览器中的ICE状态机可提供这些信息，如在检查候选地址时，ICE状态机可提供有关会话进度信息。建立会话后，如果ICE持续同意检查失败，则表明会话终止。

4）当会话双方同时尝试建立或者更改会话时，实施双占用分解 当通信会话双方同时尝试建立或者更改会话时，就会出现双占用问题。这可能导致会话出现无法确定的状态。而SIP等信令协议内置有双占用分解功能，如果在WebRTC中采用这些方案，将大大减少双占用问题引起的处理需求。
二、信令的传输 1）HTTP/HTTPS传输 终端可发起新的HTTP请求，以便向服务器发送信令信息并从中接受信令消息。信令消息可使用GET或POST方法或以应答形式传输。

2）WebSocket传输 WebSocket传输允许终端开通一个与服务器的双向连接。此连接最初采用HTTP请求形式，随后就会升级为WebSocket。

3）数据通道传输 数据通道模型基于WebSocket建立，具有简单且可设置的send方法和onMessage处理程序。

• 信令服务器 是实现WebRTC通信很重要的一个部件，主要负责交换2个终端的候选地址（Candidates）和媒体信息描述文件（SDP）。

  当2个终端都在NAT后面时，双方都不知道对方的地址也无法连接到对方，而且双方也不知道对方所支持的媒体类型以及是否支持某些特定的网络协议。因为需要一个身处公网的服务器（信令服务器）来为双方交换这些信息。 信令服务器也可以起到房间管理的作用。可以在整个通信过程中与双方客户端始终保持长连接来通知双方房间状态，比如有人离开，会议结束等等。 信令服务器仅用于发送一些命令及转发一些连接用的信息和媒体信息，不能用作TURN服务器，TURN服务器是用于在双方无法建立连接的时候代为转发音视频流数据包的。不是必需的，而信令服务器是必需的。

• WebRTC中信令方案的对比

方案	服务器要求	优点
WebSocket代理	提供服务器代码的WebSocket服务器	无需信令架构基础
XML HTTP 请求	提供服务器代码的Web服务器	无需信令架构基础
SIP	支持SIP WebSocket传输的SIP注册/代理服务器	易于与SIP终端或基础架构互操作，无需服务器代码
Jingle	支持XMPP WebSocket传输的XMPP服务器	易于与Jingle终端或基础架构互操作，无需服务器代码
数据通道	用于建立数据通道的WebSocket或Web服务器	信令延迟短并可保护信令隐私

---

了解一些基本概念之后

• WebRTC、SIP、XMPP(Jingle)区别 1）WebRTC提供了一系列API，用于实时通信。而它最终会发出一些会话描述协议（SDP）行，来描述终端之间的媒体会话。但是WebRTC没有给你任何与其他人交换SDP的方式。所以我们可以使用现有的信令通道或者自己实现信令通道来进行SDP交换。

  2）SIP是现有的标准化信令协议。已被应用于电话通讯。SIP直接处理SDP，但实际上，SIP有一些限制，其中之一就是几乎不可能弄清楚另一个端点是否能够连接回来。另一个原因是SIP在网络浏览器中嵌入是非常棘手的。

  3）XMPP（可扩展消息传递和联机状态协议）通常用于即时消息传递和联机状态。有一个名为Jingle的信令协议，是对XMPP协议的扩展。它向XMPP添加了媒体信令功能。Jingle是一个支持语音和视频的XMPP扩展。利用Jingle,可将SDP会话描述映射至XML格式，再通过TCP或TSL传输至XMPP服务器。谷歌（仍然）将其用于环聊，会议等。XMPP的巨大优势在于它可以在纯TCP上运行，也可以在Websockets上运行，并且非常容易通过HTTP进行隧道传输。这些都是标准化的，所以可以选择多种服务器进行部署。

  4）因此，WebRTC是一个标准规范(也是一个开源项目)，旨在支持跨浏览器使用实时语音、视频和数据通信。WebRTC本身没有信令。但它需要信令来在两个会话终端交换SDP。这个信令协议可以是Jingle（xmpp的扩展协议），SIP或自己编写的任何支持传输SDP的信令协议。

• WebRTC建立会话主要步骤 1）获取本地媒体 （getUserMedia()）

  2）在终端之间建立连接 (RTCPeerConnection)

  3）将媒体数据和数据通道关联至该连接 (RTCPeerConnection)

  4）交换会话描述 (RTCSessionDescription)

• 主要API简介