Licode—基于webrtc的SFUMCU实现
webrtc的前世今⽣、编译⽅法、⾏业应⽤、最佳实践等技术与产业类的⽂章在⽹上卷帙浩繁,重复的内容我不再赘述。对我来讲,webrtc的概念可以有三个⾓度去解释:js代码加密软件
(1).⼀个W3C和IETF制定的标准,约定了Web间实时⾳视频通信机制,通过该标准可开发基于浏览器的、⽆插件的web多媒体应⽤(⼀般是js),该标准仅设定了点对点⽆中⼼的实时会话场景,没有强制约束信令协议与内容,没有要求有媒体处理的中⼼服务器,主要⽬标是形成开发者与浏览器⼚商良好的⽣态环境,并积极向HTML5靠拢争取被纳⼊进去;
(2).⼀⾳视频算法和⽹络适应性算法,这些算法囊括了视频会议⼏乎所有的核⼼技术,包括⾳视频的采集、编解码、⽹络传输、播放显⽰、安全等功能,还提供了操作系统系统调⽤跨平台封装的实现,包含Windows,Linux,Mac,Android,iOS;
(3).⼀个开源⼯程,核⼼由c++实现,可通过修改、封装、提取代码等⽅式实现⼀套视频会议系统,客户端可实现为Web js、App或Windows 应⽤程序等多种形式,服务端可实现包括业务外的所有服务,包括媒体服务、信令服务、穿墙服务、中继服务等等,这些服务稍微调整后可轻易⽀持分布式部署、容器部署、云部署等。
对webrtc的理解与使⽤,我认为有三个境界:
(1).能搭建⼀个简易的视频会议系统,其中客户端部分可以这样做: Windows端Mac端Linux(x86)端在⾃带的peerconnection client或libjingle改⼀下(取决于信令是http还是sip家族信令);Android/iOS端在apprtc或licodeAndroidClient及Licode-ErizoClientIOS改⼀下;web端⽤webrtc ⾃带js api实现⼀下。服务端部分可以这样做:信令服务器在apprtc的collider改⼀下;穿墙服务器⽤⾃带的stun
server,turn server部署⼀下;中继服务器在⾃带的relay server改⼀下;媒体服务器在kurentos、licode、jitsi、Intel Collaboration Suite for WebRTC或janus改⼀下;如果需要和传统的SIP体系互通则在webrtc2sip改⼀下;如果需要关注实时通信过程中的延时、丢包、接通率、掉线率等质量问题,可以部署callstats来进⾏专业监测;把所有服务都再部署于云平台的多个虚拟主机上或阿⾥云的容器云服务,完成以上操作就搭建起初级规模的云上视频会议系统原型了。
(2).能提取、理解并使⽤webrtc的算法模块,即或将算法模块融⼊到⾃⼰的代码中,或将⾃⼰的算法添加⾄webrtc⾥作为开源贡献或⾃⼰产品的差异性优势。值得提取的算法模块包括⾳视频编解码与处理框架(vp8、vp9、voice engine、video engine),⾳视频采集呈现封装、⾳视频预处理(NetEq、NS、AEC、Video Jitter Buffer)、⽹络适应性(GCC算法、ARQ、FEC)、安全性(Dtls、Srtp/Srtcp)等,⾃⼰可添加的有视频编码模块(x265、nvenc、intel qsv、xavs2、以及其他定制化的⽹络传输策略)。
(3).能够结合基于rtmp-cdn/p2p等直播技术,构建既⽀持交互互动,⼜⽀持海量围观,可商⽤、能运营、易扩展、全兼容的⾳视频PaaS服务平台,完成⼀个多媒体通信的终极产品。
Licode是达到第⼀境界技术层⾯所需要了解的开源⼯程,它从webrtc代码中提取出了SFU/MCU媒体服务所⽤到的⾳视频、媒体传输、信令的功能代码,结合libnice与libav实现了ICE与媒体转发功能,并封装成了可被调⽤的js API,此外还⽤js实现了包含全局管理服务、数据库服务、业务逻辑服务与信令媒体的调⽤服务的业务代码。Licode实现了webrtc开源⼯程没直接实现的中⼼侧的媒体服务功能,并提供了简单的业务模型与分布式部署⽅式,从⽽得到了多媒体通信⼯程师的⼴泛关注。但是Licode的相关⽂档与资料⾮常少,故本⽂是在我个⼈观察运⾏调试代码后总结所写的,不正确之处希望在留⾔中能够得以指正。
2. Licode系统分析
2.1 系统架构
Licode的系统架构如下,有客户端和服务端,客户端包括ErizoClient和NuveClient,分别⽤来进⾏信令与⾳视频交互和业务操作,类似于终端和会控集成在⼀起;服务端包括Nuve、ErizoController、ErizoAgent和MessageBus,分别⽤来实现业务服务与全局管理服务、信令服务、媒体服务和服务通信,其中ErizoController类似于MC、ErizoAgent类似于MP。
图1 系统架构图
2.2 客户端与服务端交互流程
客户端与服务端的交互流程如下图所⽰,其中客户端代码集中在N.API.js与Client.js上,服务端代码集中在nuve.js与erizoController.js上。
图2 信令交互图
3. 系统组成与模块划分
3.1 系统组成
本系统组成仅指服务端的系统组成,包括Nuve业务管理服务,ErizoController信令服务,ErizoAgent媒体服务,ErizoJS媒体转发实体。个⼈觉得代码在⽂件命名与⽂件组织结构上⽐较乱,初学者不易理解,如erizo_controller⽂件夹包括了除nuve以及webrtc的js api之外的所有js代码,不仅仅是erizoController,此外webrtc核⼼部分命名为erizo,也让⼈与整个系统相混淆。系统组成如下图所⽰,⼀个Nuve管理多个ErizoController(以下简称EC),⼀个EC管理多个ErizoAgent(以下简称EA),⼀个EA管理多个ErizoJS(以下简称EJ),⼀个EJ就是⼀个SFU,封装了C++实现的webrtc、libav与libnice。
图3 服务端系统组成图
3.2 Nuve业务管理服务
图4 Nuve业务管理服务
图5 Nuve各模块⽤途及对应⽂件
此外,这篇⽂章Licode(⼆):Nuve源码分析 - CSDN博客 对Nuve做了更详细的分析。
3.3 ErizoController信令服务
图6 ErizoController信令服务
图7 ErizoController各模块⽤途及对应⽂件3.4 ErizoAgent媒体服务
图8 ErizoAgent媒体服务
图9 ErizoAgent各模块⽤途及对应⽂件
3.5 ErizoJS媒体转发实体
图10 ErizoJS媒体转发实体
图11 ErizoJS各模块⽤途及对应⽂件
3.6 webrtc
由于webrtc⼯程代码本⾝⾮常庞⼤,编译⼯具也很独特,Licode并未全部引⼊,仅仅抽取了webrtc的部分代码,如下图所⽰

版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198,我们将在24小时内删除。