WebRTC网关服务器搭建:开源技术 vs 自行研发

  • 时间:
  • 浏览:4
  • 来源:5分3D_5分排列5

4月,即构WebRTC网关服务器正式上线,并实现了APP、微信小系统应用应用程序、WebRTC三端的连麦互通。WebRTC网关服务器的上线意味着着即构的音视频能力都时需全面支持网页端视频互动场景。

村里人 都知道基于WebRTC的延伸,目的是实现实时通话并且 是多方通话,是没人服务器的概念。下图是我对WebRTC通信模式的总结,左边是基于P2P法律法律依据对WebRTC进行延伸,我把它称为P2P模式,右边则是加入了服务器的模式,我把它称为服务器模式。

其次,通过自研都时需淬硬层 掌握相关技术,还里能 根据自身业务特点对框架进行针对性的定制和性能优化。虽然 WebRTC的体系非常比较复杂,并且 上边涵盖的RTP、RTCP、DTLS、NETEQ等技术要点是十分值得学习的。

村里人 都知道现今直播的发展要得益于CDN整理体系,CDN主要通过RTMP协议进行传输,而WebRTC的传输协议是RTP/RTCP,所以并且 村里人 时需使用CDN网络进行整理,就时需在服务器中将RTP/RTCP转成RTMP。在WebRTC中,编码格式是OPUS,而RTMP协议对应的编解码格式一般是AAC,通常你是什么种编码格式之间的转换也是非常现实的需求。同时,在MCU模型中,村里人 还都时需在服务器中增加录制、混流的功能,在直播连麦的情况汇报下,通过混流的法律法律依据都时需大大减少下行的强度。

以上所介绍的模型否是其他人 的优缺点,村里人 应该根据具体的业务场景进行选择,所实现的功能也并否是太满越好。

● WebRTC通信模型的对比,分析不同的模型对应的适用场景,以便村里人 在选型时能结合其他人 的需求匹配对应的场景。

村里人 好,我是黄开宁,来自即构科技,从事音视频开发并且 超过10年了,虽然 没人,在技术飞快更新迭代的时代,村里人 还是时需时刻保持学习的情况汇报。今天,我主要跟村里人 介绍以下5个方面的内容:

表格中所列出的开源系统是目前市面上比较常见的,分别从服务器类型、编解码能力、文档的完整性性和开发商来进行对比。村里人 都知道WebRTC的服务器模型有一种,分别是SFU和MCU,SFU实现的是简单转发的路由功能,而MCU都时需提供更多扩展性的功能实现,并且 MCU型的服务器往往涵盖SFU,所以MCU的实现难度较大。其次,文档的完整性性也是非常重要的,并且 对于开发者来说,文档具有非常重要的指导作用。最后是开发商,其他主要涉及到项目的可持续性、升级支持以及版权疑问图片,对于商业机构来说版权的疑问图片时需谨慎考虑。

首先,目前的开源项目无须能完整性满足业务需求。以上介绍的开源系统否是是基于分布式架构,并且 要实现大型分布式架构并且 后台,时需投入几瓶的开发人员和时间对现有架构进行改造,从成本和强度上来看,与自研相差不大。

● Licode具有SFU和MCU功能,它的架构是插件式的,也并且 说,并且 你想在其他人 的源代码上附加其他功能,都时需直接使用Licode对其他人 的系统进行补充,既能保留原有系统的社会形态,又能达到完善功能的目的。

上图是NVN的模型,一般用于多方会议。在P2P模式中,并且 各个点都时需在上行和下行传输,所以强度是n-1。而在右边的服务器模式中,只时需上传一路到媒体服务器,而下行中通过SFU模型都时需选择,接收媒体服务器中完整性并且 其中某一路。从强度上看,上行只时需1M的强度,其他上下行强度不对称的服务器模型明显比P2P模型更好。而随着这接入服务器的用户数量增加,接入到SFU媒体服务器的服务器模型的优势就更加明显。

● Janus的出发点是网关,它的开发商是Meetecho公司,Slack推出的视频通话方案并且 基于其他开源系统的。但在测试过程中发现,其他开源系统在性能上其他疑问图片, 而Slack也是对其进行了几瓶的优化。

作为实时音视频领域最火的开源技术,WebRTC 点对点的架构模式,无法支持大规模并发。要怎样在架构中引入服务端,老要是开发者关注的热点。5月20日,即构科技资深音视频架构师黄开宁在WebRTCon大会上带来了他的经验分享,以下是对他演讲内容的整理。

在线医疗的场景中否是同样迫切的需求。在上个月,我的汽车出了点小意外,在现场等了将近4个 半小时后,保险专员才到达现场进行解决。并且 能直接通过手机浏览器,接入某个保险公司的客户专员进行在线定险,并且 10-20分钟就能解决疑问图片。就像车辆碰撞,生病虽然 否是4个 小概率事件,没人必要在手机中安装4个 医疗软件。假使 在户外被莫名的东西咬到而冒出了敏感的情况汇报,其他以前直接通过浏览器进行在线问诊,显然比安装4个 APP要方便的多。其他是从需求上出发,也是浏览器迫切时需WebRTC网关的意味着着。

还有一种是1VN模式,并且 村里人 所熟知的直播模型。P2P模式是根据用户数量进行上行传输,而在直播中,4个 直播间的用户数量并且 是十万甚至是百万的数量级,所以P2P模式不适用于直播。目前的直播否是使用服务器模式,在上行没人1M的强度情况汇报下,主播传输视频流到服务器,由服务器进行下行的整理。并且 经过服务器,村里人 都时需对服务器的能力进行最大限度的扩充,这类实现多级整理体系等,提高整理的强度。在直播和监控中,并且 的多级整理体系应用非常广泛。

从现实需求看,自研也是十分必要。就像即构通过自研RTMP方案用于实时互动,其最低延时都时需达到400毫秒。说明村里人 对RTMP标准的社会形态十分了解,甚至都时需根据不同的需求对框架进行特有的设计并且 是有针对性地进行性能优化,这也是即构的优势所在。

总的来说,无须同的应用场景看,在系统中加入WebRTC网关几乎并且 是大势所趋,对于具体的应用场景,基于WebRTC的延伸都时需分为一种通信模型:P2P模式和服务器模式,在实际应用中应该根据不同的需求进行选择。尽管目前市面上并且 有不少的开源系统,但哪些开源系统否是其他人 的优缺点,不一定能满足用户需求,在并且 的背景下,即构选择了自主研发系统。

● Intel使用Licode实现了4个 Intel CS for WebRTC的套件,它是免费的,有提供Client端和Server端的SDK,并且 其他系统不开源。村里人 在其他沙龙活动中会老要都看有关其他系统的介绍,基于其他系统配合使用Intel方案也是不错的选择。其他系统也是列表中唯一支持RTMP转协议的系统。

以前是基于媒体的淬硬层 分析了有关WebRTC网关的通信模型,接下来介绍一下SIP信令网关相关内容,尽管目前SIP在国内无须常见,并且 在国外还是比较普及的。首先村里人 时需了解SIP通信模型的概念,虽然 SIP和WebRTC还是有所以的同时点,这类,上行传输的协议否是用Offer/Answer模型,而底层协议否是RTP/RTCP。并且 时需在浏览器两端建立流媒体服务器,只时需简单的几步,并且 并且 浏览器要和4个 SIP终端通信则是非常比较复杂的,并且 信令的不对称,所以时需在信令网关中进行转换。并且 信令的转换没人统一的标准,只时需实现通信两端的SDP、Candidate的交换即可。

本文是WebRTC网关服务器搭建的第一篇,在下一篇文章中,村里人 将带来《即构自研WebRTC网关服务器构架实践》,敬请期待!

最后,无论是开源还是自研,立足点都应该是实际的需求,根据其他人 的具体需求选择最大约的方案。

目前市面上有不少的开源系统,哪些开源系统有其他人 的特点,在实际开发过程中应该根据具体的需求进行选择。

● 为哪些时需WebRTC网关?对于即构来说,目前所使用的系统并且 较为性性早熟期图片 图片 期的句子是什么是什么且经过了市场的检验,为哪些时需在没人性性早熟期图片 图片 期的句子是什么是什么的商用系统中加入WebRTC?

● Zego-Gateway架构的实践,分享即构在开发过程中遇到的其他疑问图片和解决法律法律依据。

在WebRTC 1.0标准还没人定稿以前,其他标准只具备雏形,在所以方面否是不足。而随着1.0标准的定稿,WebRTC逐渐完善,到现在并且 都时需在网页端使用,换句话说,并且 有基于WebRTC的实际应用。下面主要结合不同的应用场景来说明为哪些时需WebRTC网关。

既然市面上并且 有不少的开源系统,为哪些即构还时需其他人 研发系统呢?

P2P模式实际上是通过点对点进行传输,不时需经过任何的服务器,除了TURN和STUN服务器之外。在不时需NAT的情况汇报下,4个 用户都时需直接相连,并且 在NAT的情况汇报下,就时需STUN介入。并且 打洞无效时,则时需借用TURN。从图上都时需都看,借用TURN的P2P模式的拓扑社会形态,和右边的服务器模式的拓扑社会形态十分这类,并且 村里人 之间有明显的区别。TURN就像是4个 中转站,作用并且 简单的转发,而服务器则有更多的功能。

● 开源VS自研,主要介绍市面上的开源系统及其特点,另外完会 分析即构自行研发系统的目的和出发点。

● 首先介绍的开源系统是Kurento,其他开源系统是在表格所列出中最全能的4个 开源系统。其他开源系统支持转码,同时还有滤镜的附加功能。并且 在测试过程中,其他开源系统的稳定性否是很好。其他开源系统同时提供了4个 云服务方案,主并且 开发商为了推广云服务而开源的系统,所以性能的稳定性还有待提高。

● 最后4个 开源系统是MediaSoup,其他系统只支持SFU,底层的开发语言是Node.js。对于熟悉Node.js语言的开发人员来说,其他开源系统比较容易学习。并且 并且 其他开源系统冒出的时间不长,系统稳定性还有待提高。

你是什么种模式的优势并且 同,并且 P2P模式的用户之间是直接相连的,所以从成本上看,P2P模式的成本更低,并且 在弱网环境下,P2P模式在连通性上的表现无须理想。现在村里人 所用的微信,从成本和点对点的沟通法律法律依据上看都应该选择P2P模式,并且 实际上,微信并没人使用P2P的法律法律依据,并且 使用服务器模式,其他也是考虑到P2P模式在弱网环境下的表现。

● Jitsi并且 实现了SFU模型,不涵盖MCU,并且 功能单一,并且 4个 转化路由,所以其他系统是列表中是较为稳定的4个 开源系统。并且 并且 时需实现简单的转发功能,其他开源系统是不错的选择。

除了实现以上功能外,并且 如今的直播中美颜、滤镜几乎成为了标配,所以实现其他附加功能也是市场普遍的需求。虽然 在WebRTC中并没人提供实现美颜、滤镜的接口,并且 村里人 都时需在服务器端实现这类的附加功能。根据实际的业务需求,通过MCU多点控制单元,都时需实现这类附加功能。

接下来以强度为例,在上下行强度都为1M的情况汇报下对比你是什么个 通信模式。1V1模型中,在上行强度为1M的情况汇报下,你是什么种模型都没哪些区别,上下行强度否是1M。

以前说的1V1、NVN、1VN的模型否是在同4个 能力级上,并且 说在上行和下行中,传输协议、媒体流法律法律依据、编解码格式否是一致的,并且 说是存在同4个 体系中的。而在实际中,上行和下行都一致的情况汇报比较少,所以以前村里人 时需在上边的服务器中进行转码,从而实现具有不同能力的终端之间进行通信。其他情况汇报下,就时时需到MCU模型。

针对在线教育或这类的应用场景,村里人 只时需给准入门槛用户提供4个 试用,比如试听课程。并且 并且 试听课程时需下载APP,对于推销人员和试听用户来说否是繁琐的操作。而基于WebRTC的网页版课程试听,取代了繁重的APP下载,操作简单方便,获客变得更加容易。其他并且 即构在性性早熟期图片 图片 期的句子是什么是什么的商用系统中加入WebRTC网关的出发点,同时也是客户提出的要求。