WebRTC简介（一）

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）

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

摘要：视频会议设备中，服务器是很重要的一个设备，视频会议服务器的搭建关系到视频会议设备能否正常使用。搭建视频会议服务器时，先要购买服务器，然后安装docker以及docker-compose，配置安全组、域名解析后，开始安装部署，测试完成后，与自己的系统集成即可。在搭建视频会议服务器时，要注意的点有很多，下面一起来了解一下视频会议服务器如何搭建吧。一、视频会议服务器如何搭建

视频会议是现代职场很常见的，几乎每个职场人都在使用视频会议进行日常沟通和举行线上交流。视频会议设备有很多，服务器就是其中一个，那么视频会议服务器怎么搭建呢？

1、购买服务器

如果没有服务器的话，需要先购买一台服务器。

2、安装docker以及docker-compose

为了方便安装应用，我们需要准备Docker环境。Docker是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的Linux或Windows操作系统的机器上，也可以实现虚拟化，容器是完全使用沙箱机制，相互之间不会有任何接口。使用docker来部署应用是非常简单的，一般情况下，只需要一行命令即可完成。

3、配置安全组

视频会议功能内部采用WEBRTC技术，会使用比较多的端口，因此需要在轻量服务器的防火墙策略上放行相应的端口，要求开放的端口主要有：

22TCP：SSH端口；80TCP：HTTP端口；443TCP:HTTPS端口；3478TCP+UDP：TURN服务器端口，TURN服务器是在视频双方无法直接建立点对点连接时进行流量转发使用；40000-57000TCP+UDP：KurentoMediaServer建立媒体连接的端口；57001-65535TCP+UDP：TURN服务器建立媒体连接的端口。除此之外，请确保这些端口80，443，3478，5442，5443，6379和8888不能被占用。如果嫌麻烦而且仅仅是测试环境使用，可以直接放行所有的端口。

4、域名解析

将要使用的域名解析到服务器的IP上。如果使用的是国内的服务器，域名需要备案。如果没有备案的域名，需要选购香港的服务器。或者也可以不使用域名，直接使用IP。直接使用IP的话，需要自己来签发并配置证书并配置浏览器信任证书。

5、开始安装部署

准备工作做完以后，就可以开始下载安装了。默认在/opt目录下进行安装：首先进入到/opt目录下，然后使用openvidu提供的脚本进行安装；进入到openvidu目录里，使用熟悉的工具来编辑env文件，本文档中使用letsencrypt来自动签发证书（ov的默认选项），都配置好了以后，然后运行下面命令启动：“/openvidustart”，此命令会拉取并启动相应服务的docker镜像，执行完毕后，用dockerps可以看出启动的容器。

启动完毕后，访问https://xxxxxxxxxxxx:port验证服务器，然后在标签页多打开页面，都加入同样的房间，来测试效果。

6、与自己的系统集成

openvidu提供了各种语言和框架的SDK，包含服务端和客户端，并且提供了大量的可以直接复制粘贴的例子来使用。只要把上面的服务配置好了，只需要花十几分钟，就可以集成到自己的系统中。

二、视频会议服务器搭建有哪些要注意的点

1、视频会议服务器端带宽需要经过合理计算，才能保障带宽在会议进行时充足。而参会终端则可以在普通的adsl网络环境中参会，但是视频会议服务器端对带宽的要求一定是有线的光纤。

2、建议不要自购服务器和软件端进行匹配使用，并不是购买高端软件+高配的企业内网视频会议服务器就可以达到最佳效果。其实，这样存在视频会议软件与服务器不兼容的问题，从而导致服务器搭建的企业内网视频会议不够稳定。采用软硬一体的视频会议服务器，不经可以避免这样的风险，又可以快速部署稳定、完全、流畅的视频会议。

3、视频会议服务器建议搭建到自己公司内部的防火墙和路由器，这种私有部署的视频会议服务器，使得企业内部会议在安全性上有更具优势。

4、企业视频会议服务器搭建采用买断的方式性价比较高，而且企业内网搭建视频会议可以最大限度保证服务器端带宽的稳定，避免服务器端带宽不足导致的视频会议不稳定的问题。

a 在openvidu中，一个激活的会议由kurentoSession实例表示。当创参会者加入会议时，openvidu会创建一个kurentoSession实例。

b 在kurento服务器上，一个会议由一个pipeLine 和N N个mediaEndpoint表示。N表是参会方数量，每一个参会方会创建一个发布媒体用的MediaElement和(n-1)个订阅其它媒体流用的MediaElement，它们被编排入一个PepleLine中, 形成N N的连接。

所以，当第一个用户加入会议室时，系统会在Openvidu上创建一个KurentoSession实例，同时在Kurento上创建一个pipleLine, KurentoSession 实例引用了这个pipepline N个用户会有N个kurentoSession, 但只有一个pipleline。PipleLine的描述是在Kurento Client包里。

管理器中另外一个重要的是sessionManager，session代表的是会议，所以sessionMananger 实际就是所有具体会议的管理 在ioopenviduservercore包下的SessionManager只是一个虚类，它声明了一些会议的操作方法：

这些方法都和会议有关， 可以发现，上面的功能通常对应我们音视频软件进入会议室的功能。

开openvidu中，它的具体的实现是KurentoSessionManager，它会在server启动的时候初始化。

在III中说了，sessionid 代表的会议号，创建会议的时候会创建一个sessionNotActive（Session类）对象，代表的是还未正式使用的会议，当第一个用户首次加入的时候，才会正式使用这个会议，KurentoSessionManager的joinRoom方法描述了相关的逻辑。

与sessionNotActive不同，一个开始使用的会议用KurentoSession来表示（继承自Session），首次加入会议， 需要创建这个Ksession, 它会指定一个具体的Kurrento Server，ksession的创建需要指定具体kms，用来表示在具体哪个KMS创建会议。社区版实际上只有一个KMS，但在实现上如下图， 已经默认使用获取最小负载的方式获得kms。

sessionManager对外提供会议操作功能的统一入口，每个会议对应的kurentoSession负责实际与kurento server的通信，来完具体的会议操作。所以在kurentoSession中我们可以看到相类似的会议功能定义：

上图是一个包含有浏览器、application 、 openvidu server, 、kurento server 等在内的一个逻辑通讯图。

浏览器端加载会议应用程序，通过http协议与application server通信，完成业务请求和获取用于会议的token和sessionID

applicaiton server只负责业务请求，它通过与openvidu server通信来生成浏览器客户端加入会议需要的token和sessionID信息。

浏览器获取token和sessionid后，与openvidu建立websocket连接，它将openvidu作为webrtc中的singal server，与openvidu通信，完成建立webrtc所需要的singal通信。

与webrtc中描述的P2P通讯不同，kurento server 充当代理，与每一个参与方建立p2p连接，通过创建pipleline和编排media endpoint完成多方的通讯。 但是Kurento Server与任意参与方建立的通讯仍旧是P2P通讯。所以，浏览器会与kurento server建立webrtc连接。 他们的通讯默认是RTP over UPD, 也可以是RTP over TCP。

openvidu与kurento也是通过websocket连接进行通讯的，与kurento的通信包含两个方面：

a 作为控制方，创建pipleline，根据加入的用户创建media endpoint, 并编排他们。

b。 作为信号服务器， 与Kurento进行webrtc连接时需要的信号通讯：例如发送sdp, icecandidate，sdp响应等，由于kurento并不是浏览器端，Sdp answser的创建，也是由openvidu完成的。

Openvidu与Kurento之间的通讯编码使用json RPC方式。 kurento 提供了client 包，方便opnvidu 实现rpc调用。

41 PipleLine

orgkurentoclient包里包含一个pipleLIne类，它代表kurento server上的media pipleLine元素; 前面已经提到，一个会议对应一个kurencto pipleLine。而在openvidu中kurentoSession代表一个会议，它包含有一个pipleliene属性：

private MediaPipeline pipeline;

在首个用户加入会议的时候，会创建PipleLine实例：

查看createPipeline方法可以看到，pipleLine使用kurentoclient来创建的。

kmsgetKurentoClient()createMediaPipeline()

PipleLine创建好一个,将作为会议的具体Rpc对象负责其它对象的创建和方法调用。

42 MediaEndpoint，publisherEndpoint、SubscriberEndpoint

openvidu里定义了一个个类：MediaEndpoint。 它对应的是kurento server上MediaElement的抽象，下图是Kurento上的元素概念：

在MediaEndpoint类中，定义了三个endpoint属性，代表三种连接类型：

···

···

WebRtcEndpoint 、RtpEndpoint 、PlayerEndpoint 这三个类来自kurent client包，代表JSonrpc的客户端类，在上图的kurento元素中能够找到对应的元素。

MediaEndpoint对三个类做了风中，使用endpointType来表示当前是那种类型（也就是哪个引用有值）。它有两个子类publisherEndpoint和SubscriberEndpoint，分别表示一个用于publish的mediaElement 和用于subscribe的mediaElement 。 在前文提到， openvidu的会议在kurento server上表示NN 模型的media element关系, Server会为每一个参会者创建一个用于音视频发布的mediaElement 和(n-1)个用于订阅其它用户发布的音视频的media element，publisherEndpoint和SubscriberEndpoint对应的就是这个概念。

无论publisherEndpoint和SubscriberEndpoint是WebRtcEndpoint 、 RtpEndpoint，PlayerEndpoint中的哪个类型，它们封装的rpc对象都由 pipeline创建。

43 KurentoParticipant

openvidu中的KurentoParticipant类代表的是参会方（不同于我们平时理解的用户），每个用户加入会议后才会创建KurentoParticipant，在 "3Openvidu Server与WebRTC的通信" 的示例图中表征的是一个浏览器与Kurento server的连接。一个用户可以打开多个浏览器页面，每个加入会议的页面实际上都代表一个KurentoParticipant。

KurentoParticipant没有具体的JsonPRC对象，相反它拥有一个PublisherEndpoint和

一组subscribers，它们在kurento server刚好表示一个会议参与方：

由于KurentoParticipant代表的是会议的参会方，这个类中定义了几乎所有与publisher和subscribers 有关的操作：

44 KurentoSession

KurentoSession 代表的是一个会议，在kurento上对应的是pipeline mediaElement，但它不属于JsonRPC对象，它对pipeline mediaElement的操作是由PipleLine Jsonrpc对象来完成的，所以它包含由pipeline属性：

这个类中定义了很多会议操作的方法：

浏览器客户端在创建连接获取token和session时，并不会直接创建KurentoSession，默认的只会创建一个session对象，并把它放在sessionNotActive组里。当用户Join会议的时候（调用 KurentoSessionManagerjoinRoom(Participant participant, String sessionId, Integer transactionId) ），才会创建KurentoSession 实例。