WebRTC学习笔记（二）之文档学习

     着手开始学习WebRTC得前先整体上有个认识，于是学习了官网推荐的文档《WebRTC - APIs and RTCWEB Protocols of the HTML5 Real-Time Web 》。

       这个文档描述的比较全面，很有参考价值。结合自己的理解总结如下：

Contents

1. Introduction to Web Real-Time Communications

1)、浏览器通过运行服务器发送过来的JavaScript/CSS/HTML代码和服务器进行信息交互。它们之间通过http或websocket等通道来完成

图1  Web Browser Model

2)、WebRTC系统种类多样，配置好相应服务器后，可以多种各种终端接入，如电脑/平板/手机浏览器、Sip终端、Jingle终端、电话等。​如图2所示：

图2 Elements in a WebRTC Environment

 

Chapter 2 How to use WebRTC

2.1 建立WebRTC会话

图3 WebRTC Session Establishment, API View

      如图3所示，建立一个WebRTC会话需要执行以下四个步骤：

1)获取本地媒体流。如使用getUserMedia()来获取本地音视频媒体流，使用MediaStream API将多路媒体流合并。​

2）初始化PeerConnection。WebRTC的核心就是PeerConnection,它用来建立浏览器之间的连接，每一对终端之间需要建立PeerConnection，即聊天室内如果三个人，他们之间两两通信就一共3个PeerConnection对象。​(这和我阅读代码不一致，代码中是每对用户分别初始化了一个PeerConectioin对象，即三人聊天室有6个PeerConnection对象)

3)将媒体流添加到PeerConnection中，当通信建立后以便进行媒体流交互。

4)当被呼叫时，浏览器之间进行信息协商，交换sdp（Session Descritions）信息，sdp中包含了用户的音视频编解码、带宽等信息，最后通过http或websocket通道发送到远端浏览器完成信息交互。

      交互sdp信息后，再开始打洞穿网并交互外网地址，留在后续章节中介绍。​

2.2 WebRTC应用实例​

图4 WebRTC Triangle Call Flow

      通信过程简单分析:

1)A/B浏览器先通过http方式访问服务器，获取JavaScript等脚本文件；

2)通过offer/anwser进行媒体会话，通过服务器交互sdp信息；

3)打洞穿网及协商后建立通话。​

​

3.WEBRTC PEER-TO-PEER MEDIA

3.1 Media Flows without WebRTC

      浏览器没有使用WebRTC也能建立媒体流。但当多用户接入时，这些媒体流也必须经过服务器，这很容易让服务器不堪重负，导致网络拥塞。​

图5 Media Flows without WebRTC

3.2 Media Flows with WebRTC

      WebRTC中的RTCPeerConnection API让浏览器之间能够建立之间点对点连接，减轻了服务器负担。大多数互联网协议，特别是采用C/S结构的协议很容易穿越NAT(网络地址转换),但点对点的协议由于NAT和防火墙的限制，却有很多困难。所以需要打洞穿网。​

 

图6 Peer-to-Peer Media Flow with WebRTC

3.3 Introduction to Hole Punching

       我们一般使用的终端都通过许多路由器映射，而两个终端之间通信需要知道对方所有的内网地址、中继地址、外网地址等，下图显示内网地址到外网地址的的映射。

图7 Public and Private IP Addresses and NAT

       那如何获得外网地址呢？我们可以通过访问Stun或Turn服务器来获得(如图8、图9)，不同的穿网服务器能穿越不同的NAT类型，关于NAT类型的介绍和穿网服务器的搭建在下一篇文章中介绍。

图8  Browser use of STUN Server

       打洞的先决条件：

1.两个浏览器要直接连接双方必须同时发送hole punching packets。

2.两个浏览器要尽可能多的知道能够到达他们的地址。

3.万不得已时，双方的公有IP地址需要中继。

图9 Media Relayed Through TURN Server

       图中显示TURN server为一个单独的服务器，TURN服务器实际上就是STUN服务器加了中继功能，它们大多情况下是在一起的。开源的turnserver-5766就包括了STUN服务器功能。

3.4 Interactive Connectivity Establishment

       ICE是一种作为穿网过程中的一种综合解决机制，具有很大的优势。当用户不能通过STUN服务器打洞时，ICE会选择TURN服务器进行中继，保证会话的进行。

图10 the basic steps in ICE

       如图10所示，基本过程如下：

1)用户访问stun服务器获取传输地址candidates；

2)Candidates在浏览器之间通过信令通道中交换，交换的顺序有优先级，一般是：host candidate,reflexive candidate,relayed candidate；

3)媒体流传输之前进行检查，直到所有checks全部完成；

4)开始媒体流传输；

5)媒体流传输过程中，为了确保在媒体会话过程中NAT映射和过滤机制不会超时，每隔一段时间检查一下网络链路是否畅通，如果发生异常，则需要重新连接。

 

4.WebRTC Signaling

4.1 The Role of Signaling

       在实时通信中，信令有一下几个作用：

1)进行媒体协商或设置。浏览器之间通信之前需要相互交换SDP(Session Description)会话信息，SDP包括媒体类型（audio,video,data）、编码类型（Opus,G.711,etc）、编码参数或设置和关于带宽的信息。

2)会话者身份的认证和鉴权。比如认证可以通过传递URL来确定。

3)控制通信过程。如会话的开启、关闭、发生错误的处理等。像SIP,Jingle或某些专有协议能提供会话控制。

4)容错处理。当会话发生异常时，比如会话双方同时尝试建立或改变会话，信令机制能够提供比较完善的解决方案，以提高系统的容错能力。

4.2 Signaling Transport

       WebRTC要求在两个浏览器之间双向的信令通道。有三个常见的WebRTC信令传输工具：HTTP,WebSockets,data channel。

4.2.1 HTTP Transport

图11 Signaling using HTTP Polling of Web Server

       浏览器和服务器通过http通道进行信息交互，其特点是消息传输只能由浏览器发起，当服务器要像浏览器传输数据时需等到浏览器发送请求。这种机制称为polling(轮询),如AJAX。

4.2.2 WebSocket Transport

图12 Signaling Example: WebSocket Proxy

       WebSocket Transport允许浏览器和服务器进行双向的连接。连接是以HTTP请求开始，随后通过WebSocket升级，当WebSocket连接建立后不需要http协议参与。它允许服务器主动向浏览器发送消息,不必等待。

4.2.3 Data Channel Transport

图13 Data Channel Proprietary Signaling

       当Data Channel在浏览器之间建立连接后，能够提供了适合信令通道的直接低延迟连接。​

 

如有问题，敬请交流指正！