基于WebRTC的视频会议系统开发
2019-03-11石芮成洪豪孙立民
石芮 成洪豪 孙立民
摘要：现行视频会议系统在实现视频会议功能时，大都需要特定的客户端软件支持，造成不同客户端之间无法进行音视频通信。针对该问题，本文设计并实现了一套基于WebRTC（Web Real-Time Communication，WebRTC）的多人视频会议系统。该系统采用基于集中混合型视频模型实现，该模型对终端用户减少了带宽要求，并且，各终端音视频流在混流前可以进行静音压缩，增强系统灵活性。结合依托于Kurento的WebRTC作为中间流媒体服务器的支持，实现媒体路由/调度的组通信，用于多人视频通信技术。通过将系统投放到实际单位使用检测表明，该系统在多人会议方面系统运行稳定，视频画面清晰。
关键词：WebRTC;即时通信;多人视频会议;Kurento;会议模型
0引言
现行用于视频会议系统的软件，大多是安装在设备上的基于C/S构架的独立应用程序。传统视频會议功能类的软件都需要有特定的客户端软件支持，如微信、QQ、SLype。这就会造成不同客户端之间无法进行音视频通信，无疑加大了硬件端的负载。复杂的视频编解码问题、通信协议、回声消除、去噪等复杂性很高的专业性问题，是传统视频通信类软件所面临的难题。而自GooCle推出web实时通信技术（web Real -Time Communication，webRTC）以来，这种能够跨平台通信的开源技术，能够直接为web浏览器提供支持语音和视频会议及数据共享的能力，无需下载专用应用软件或插件。现阶段各大浏览器都实现了对webRTC的支持，Google Chrome、Mozilla Firefox、Microson Edge、AppleSafari等等，不同浏览器视频通信可以相互兼容，视频会议向着跨浏览器视频通信的方向发展，使得视频会议系统更加方便、更加易于获得，以满足用户需求。凭借以上技术优势，WebRTC即将成为新一代实时音视频通信的技术标准。
本文介绍了webRTC的总体架构与关键技术，阐明了web应用中信令层与媒体层逻辑关系，并完善WebRTC应用中媒体层面实现的不足。采用kurento新型媒体服务器将WebRTC与现有的服务器模型相结合并实现其在实际系统中的应用。开发基于webRTC的视频会议系统，对研究和开发基于IP网络的跨浏览器视频通信具有重要的价值和意义。
1 关键技术介绍
1.1 WebRTC
作为网络视频的一项新技术。WebRTC不是服务。也不是应用程序，是一个支持网页浏览器进行实时语音对话或视频对话的API，WebRTC的总体结构分为三大部分：开发者基于实际开发多媒体应用的Webapp层、封装有通信协议及媒体处理引擎模块的Web API层、由浏览器商自主实现的输入输出层。
在WebApp层，开发者根据自己的意愿选择开发实时音视频通信的多媒体应用，开发使用的多媒体应用大多基于集成了Web API的浏览器。
Web API层集成了实时音视频通信所需要的通信协议与媒体处理引擎。通信协议由承载协议和信令协议两部分组成：承载协议使用Websocket全双工通信协议，一次握手建立连接后便始终保持连接，在建立的全双工连接上传输数据：信令协议使用SDP协议与JSEP协议对音视频通话进行会话控制与媒体协商。SDP消息中包含了媒体协商必需的相关参数，JSEP（Java Session Establishment Protocol）协议对音视频通话开启会话控制。
输入输出层实现音视频捕获与媒体信息流的读取，此部分由浏览器厂商根据自己的需求进行自定义。
1.2 kurento
Kurento是一个WebRTC媒体服务器和一组客户端API。其完善了webRTC媒体处理引擎，提出一个多媒体框架。简化Web和智能手机平台的高级视频应用程序的开发。
提供多种方法改进升级原有WebRTC多媒体应用程序：在原有的媒体处理技术基础上，音频编码器中使用Opus编码器代替传统的iSAC与iLBC编码器，其可以覆盖人类听觉系统整个范围，采样支持从8-（4kHz带宽）48kHz（20kHz全频）的采样率，支持固定比特率和6-510kbps可变比特率，帧大小从2.5-60毫秒：视频编码器中使用H。264视频编解码器，视频传输时被组织成网络抽象层单元（“NAL单元”），使用面向字节流格式或面向分组格式传输：视频编解码延时小于200ms，满足实时视频通信的低延迟特性要求。采用MKV格式（Matroska容器格式）用于录制。在传输方面，kurento可以管理标准RTP/RTCP流，实现网络的传输与流控等功能，SRTP/SRTCP流为传输的数据提供加密、消息认证、完整性保证和重放保护。此外使用Gstreamer支持任何编解码器之间的自动媒体转码。
2视频会议系统分析
2.1 视频会议系统的需求分析
为了实现在尽可能减少带宽使用率的前提下，对一场群组视频会议的管理，系统遵循着完备性、正确性和逻辑性的原则。并根据视频会议的具体功能和业务流程分析核心业务需求。
2.2 视频会议系统业务流程
根据上述具体功能分析。得出群组视频会议业务流程如图1所示。可以通过接受kurento媒体服务器发起的视频呼叫进入规定的会议：也可以通过访问kurento媒体服务器的URL进入当前会议。
3 视频会议系统模型实现
3.1 视频会议系统模型设计
视频会议模型根据信令服务器与媒体服务器对节点的控制关系可以概括为两大类：紧耦合模式与松耦合模式。紧耦合是指由一个中心节点实现信令集中控制的会议：松耦合是指无需中央SIP信令的控制，终端直接进行交互的会议。其中紧耦合会议又可分为端系统混合模式、集中混合模式和信令集中、媒体流分布模式。
本文中视频会议模型选择使用紧耦合会议模式下的集中混合型视频会议模型。此模型中终端各成员间的通信通过一个核心的混合器来实现，每个终端成员均需与混合器建立媒体和信令的连接，每个终端只收到一个混合流，对终端用户减少了带宽要求，用户可以自由选择编码格式：音视频在混流前可以进行静音压缩，增强系统灵活性。与本文提出的服务器模式相一致，本系统中的核心混合器使用信令服务器与kurento服务器：信令服务器建立与各终端联系并负责对所有成员进行呼叫控制。kurento服务器进行媒体流的混合分发。系统模型如图2所示。
模型中双向虚线代表各节点与混合器中信令服务器交互产生的信令流，双向实线代表各节点与混合器中kurento媒体服务器交互产生的媒体流。
3.2 模型流量控制算法设计
3.2.1 系统模型角色定义
一场会议当中的角色分为主持者（Initiator）和与会者（Participant）。每個角色在模型中都被定义为一个节点，视作模型中一个视频会议对等体。每个会议节点都能进行节点初始化、媒体流发送与媒体流接收。除此之外，主持者节点还需要发起整场会议（包括设置发起会议的名称与选择与会人员等）和负责选择切换当前窗口。
3.2.2 算法流程
会议系统整体流程可以抽象为以下两种算法表示：使用算法1初始化会议中所有节点，执行会议选择算法从初始化后的节点中选择主窗口节点。
算法1初始化算法
Procedure：lnit
Input：t为会议主持者节点，Rk为与会者节点集合，本次会议集合为C
Output：
（1）BEGIN
（2）令与会者节点集合Rk为空
（3）Start_listen（t）//初始化
（4）Rn=req_sel_par（t，Rk）//主持者选择与会人员
（5）END
其中。Start_listen是主持者节点初始化整场会议，包括设置会议名称、发起会议规模等;req_sel_par表示与会人员通过‘接受来自视频会议呼叫信息，t选择与会人员集合。
算法2会议系统选择算法
Algorithm：select
Input：Ek（k=1，2，…，n）请求与会人员列表，T主持者节点，Nj当前窗口状态，S会议状态
Output：当前输出音频节点
（1）if（s==1）{//当会议正在进行时
算法中req_tran_media表示当选中当前窗口时，当前窗口作为主窗口媒体流的传输，将媒体流信息分别发送到各个节点：没被选中的窗口处于静音状态，只能接受主窗口命令。
3.3 系统架构设计
根据上述关键功能的需求分析，围绕核心业务设计系统架构，如图3所示。整个系统架构以视频会议为驱动，采用软件架构中MVC多层架构设计思想搭建而成。
图3中信息访问层即表现层，为用户提供多种接人渠道访问本系统，保持与控制层对应关系;服务应用层实现控制层与业务层功能，使用WebRTC协议提供搜索引擎服务、工作流服务支持，解释用户的请求并将其映射成可执行的操作，根据具体的需求来进行业务逻辑处理：应用支持平台实现对数据访问层与数据储存层支持。kurento服务器包含了系统中视频有关流的所有核心数据，jeecg框架提供权限控制服务支持，用来对数据存储层的数据进行直接增、删、改、查等操作。在系统的数据传输层搭建信令服务器，使用UDP提供逻辑连接的建立、传输层寻址、数据传输、传输连接释放等。将通信双方需要交换的相关参数封装在SDP中传递给通信双方。
3.4 系统模型服务器端实现
模型中的核心混合器端由系统中信令服务器与kurento媒体服务器实现。每个终端均需与系统服务器端建立媒体和信令的连接。通过信令服务器与所有通信端点建立连接，负责获取初始信息并建立媒体流传输通道：kurento媒体服务器对各个端点发送来的媒体流混合处理，将其发送到各个端点。每个终端仅会收到一个混合的流，减少了计算复杂性：通过使用kurento媒体服务器中的GStream多媒体库，对来自各个终端的编码需求处理，终端可以自由选择编码格式：并对除主持人外的与会者的音频流使用端点静音算法压缩处理，减少了带宽的使用率，系统灵活性增强，并使会议可以接受不同网络带宽性能的多样终端端点参与。系统服务器端通信架构如图4所示。
3.4.1 信令服务器搭建
信令服务器主要用于会话控制与媒体协商，具体的信令实现过程是基于WebRTC提供的弱信令API-JSEP（JavaScript Session EstablishmentProtocol，JavaScript会话建立协议）来实现。媒体协商在接到目标用户所在浏览器或终端传来的SDP协议格式消息以后开始，调用JSEP信令API的createOffer（）/createAnswer（）接口，生成SDP（Session Description Protocol），为通信双方交换的会话描述内容提供会话描述格式，保存通信双方需要交换的相关参数，SDP消息中包含了媒体协商必需的相关参数：由浏览器调用WebRTC内置API实例化RTCPeerConnection对象获得自我会话描述并使用内置函数localDescription将其保存，通过信令通道发送到另一客户端，由此完成交换会话请求和应答消息，从而完成通信双方会话的创建。
媒体协商成功建立链接后进行媒体流传输，通过信令消息对音视频通话开启会话控制（会话开始、结束、信息修改等）。会话控制也调用JSEP（Java Session Establishment Protocol）协议，其没有定义具体的实现协议，由开发者在开发时自行选择即可。此系统中使用SIP协议实现。
3.4.2Kurento服务器搭建流程
视频会议模型中核心服务器使用kurento媒体服务器进行处理媒体流。通过Websocket全双工通信建立kurento客户端与kuremo media serve公开的API之间的连接，使用kurento提供的kurento协议来对客户端与kurento media serve之间的通信提供不同类型的请求/响应消息，以完成kurento客户端对kurento media serve执行的操作。
（1）首先建立客户端与kurento media serve之间的websocket链接。使用kurento协议中提供的ping方法，作为客户端发送方发送的链接方法，发送给接收方。
（2）创建用于传输的kurento媒体对象。使用kurento协议中create消息创建。在create消息中的type参数中指定创建媒体对象类型。如媒体管道和媒体元素等：接收方接受到发送方的create消息后，返回sessionID参数，用于创建下一步的创建请求。
（3）创建对象完成，对创建完成的媒体对象执行相应的操作。kurento协议中invoke消息是用于定义要执行的操作，参数operation用于定义将要执行操作的名称。例如connect进行连接操作等。
（4）与会者需要订阅主持者发布的视频流。执行kurento协议中subscribe消息。参数id定义为主持者id，type参数定义订阅视频流类型，主持人端收到订阅消息后，触发onEvent事件，从服务器端请求视频流数据。使用unsubscribe消息取消对主持者端的订阅。
（5）会议结束后释放不使用的对象。使用release消息用于释放不需要的对象及其资源。
4 结果展示
4.1 系统开发环境搭建
PC端使用ieecg面向学习型的开源Java EE开发框架。在spring-boot核心框架基础上搭建的一个Java基础开发平台，使用Vue作为编写展示层框架实现浏览器端HTML/is页面，使用MyBatis技术实现数据访问层、控制层及业务逻辑层使用spring-boot框架操作，ApacheShiro为权限授权层。Ehcahe对常用数据进行缓存，thymeleaf做为模板引擎，数据存储层使用Oracle大型数据库等MVC多层架构的设计模式。
4.2 视频会议系统应用场景
本模型的应用实例是税务总局对下属十六个县市区税务局召开视频直播会议，要求各下属税务局逐个进行工作情况汇报。
在如图5所示的界面中，由税务总局主持人（会议发起者）选择需要邀请的用户列表权限，后台对数据库中所选中的邀请用户进行角色权限搜索遍历，用户角色权限符合，对其发起视频会议呼叫。
用户接受呼叫邀请进入视频会议界面，待所有用户都加入到会议中后，主会议页面使用响应式栅格化方式，自动分配每个用户窗口和屏幕大小，（各分局页面为主持人端与本客户端）如图6所示。
窗口则需要执行静音算法，即不对当前进行的汇报产生干扰，也减少对网络带宽的使用。经过实际测试表明。本会议模型可建立基于P2P的16路對等视频会议。在会议时长持续24小时中，会议过程视频流畅，无卡顿现象。
5 结束语
WebRTC是基于浏览器的实时通信，是指运行在浏览器上的Web应用通过调用浏览器提供的API，实现浏览器之间实时通信连接的建立和音视频等数据的传输。本文基于这种新型的直播技术提出一种视频会议系统模型，改变传统的视频会议全连接模式，由主持人端发起会议，接受其余全部与会人员视频流信息：与会人员只需接受主持人端视频，减少服务器端负荷：对除发言窗口外其余窗口使用静音算法来减少带宽使用。根据视频会议模型设计的视频会议系统。并应用到税务部门实际工作中，进行反复检测用户加入数量对视频会议带宽影响。下一步工作中，对现有的静音算法优化，降低多用户状态下切换目标时产生的延迟。
