FreeSWITCH视频会议“标准”解决方案

转自 LiveVideoStack公众号 https://mp.weixin.qq.com/s/LOCxUNBA1j94qJPqY1RKrA

我们所谓的“标准”解决方案，并非是指这个解决方案是标准的。而是在做视频会议的过程中，FreeSWITCH作为一个服务器，会面对不同类型的客户端以及各种硬件的终端。由于它们使用了各种各样的标准协议，是我们没办法修改的，所以称它们为标准的客户端。而FreeSWITCH视频会议“标准”解决方案就是指针对这些不可修改的标准客户端所做的一种解决方案。

视频会议类型

视频会议大体上可以分为三种类型。一是传统视频会议，传统的视频会议是“标准”的，因为它们之间需要互通。早期的视频会议协议一般是H323，即使现在我们也还会经常遇到H323的设备，但后来大部分被SIP协议的设备所取代。SIP协议是一个文本协议，整体更灵活一些。

近几年开始出现一些云视频会议，今年其实也可以算作云视频会议的元年，由于疫情的原因，大家开始更多地使用视频会议。例如Zoom，腾讯会议、小鱼易连等，据说腾讯会议一周之内上线了10万台服务器，进行紧急扩容，这在传统的视频会议时代是不可能实现的，只有在云计算时代才能快速实现扩容，这也体现了云计算的优势。据了解这些云视频会议厂商，基本都是使用的私有协议，其好处是可以无限制的优化。但私有协议无法进行很好的互联互通，不过各个视频会议厂商为了实现与其它设备互通，自己也会提供一些SDK。

开源领域的视频会议，有FreeSWITCH、Jitsi、Kurento、Janus、Medooze等，这些视频会议也有许多年的历史了，目前大多已经开始支持WebRTC。有的以支持WebRTC为主，例如Kurento和Janus；Janus和Medooze最初是支持SIP的，最近几年我没有太关注；Jitsi对WebRTC的支持非常好。

对于FreeSWITCH，大家可能会有些误解。FreeSWITCH其实最早是用于音频通信的，即PBX 程控交换机，但实际上FreeSWITCH的视频会议功能也非常强。开源的视频会议因为是开源、开放的，使用的是开放的API，因此更多的是使用开放协议如SIP协议。

目前WebRTC比较火，所有的视频会议设备基本都在支持WebRTC，在浏览器里就可以打电话。WebRTC是一个媒体协议，没有规定信令，在信令层面没有标准，因此大家实现起来会比较灵活。FreeSWITCH在信令层实现了两种协议，一种是SIP，它承载在WebSocket上，因为在浏览器里只有WebSocket可以实现双向通信。另外还有自己实现的私有协议Verto。

互联互通

随着我们对于视频会议软件的使用越来越多，会发现一个问题：手机和电脑上的视频会议客户端越来越多。

其实我们也非常希望能解决这个问题，方法就是互联互通。我们希望所有的终端都能互联互通，难道只是因为使用的视频会议客户端不同，就不能在一起开会了吗？

理想很丰满，但现实执行起来还是很困难的。

其实更多的是由于商业的原因，没有人会选择这么做。当然从技术层面来说，全部使用私有的协议、服务器和终端，能更好地优化、更好的保证安全等等。总之，实现互联互通任重道远。

虽然任重道远，但其实我们一直想做这方面的事情，FreeSWITCH也连接了很多不同的客户端，希望能跟更多的设备进行互联互通。

FreeSWITCH的成长史

说到FreeSWITCH，简单了解一下它的历史。

2006年FreeSWITCH发布了第1个版本。FreeSWITCH本身最开始是作为一个PBX进行的。PBX就是我们所说的企业里的交换机，打电话用的。

2008年发布了1.0版本—凤凰版，像凤凰涅磐一样，经历了无数次的崩溃、优化，所以称为凤凰版。

2012年发布FreeSWITCH1.2版本（FreeSWITCH的版本号都是偶数），1.2版本非常稳定，音频方面也已经非常成熟，在电话方面基本上没什么可做的了。但随着的WebRTC的出现，FreeSWITCH决定接下来要支持WebRTC。

2014年推出1.4版本，开始支持WebRTC。早期的WebRTC还不是很稳定，但WebRTC的标准变得非常快，所以FreeSWITCH也一直在跟着改。

其实早在2008年我就开始做FreeSWITCH了，那时主要做在线教育，早期的在线教育没有视频，只有音频，教师利用音频做英语的对话教学。后来又做了一些其它的项目，要求有视频，然后就增加了一些视频的功能，包括视频的MCU。由于FreeSWITCH早期在视频方面还不是很成熟，做了几个项目不是特别满意，所以后来我们就把视频部分开源了。

2014年-2015年，我们耗费了一年的时间，将自己做的部分合并到FreeSWITCH的主分支中，用一整年的时间将自己写的代码规范化、同时适配Windows、Linux、Unix等各种平台，实现FreeSWITCH在各种平台上的编译和支持，发布了1.6版。这时FreeSWITCH开始支持视频通话和视频会议，之后从2017年开始到2020年，这几年一直在不停的修bug，将FreeSWITCH做得越来越完善。

在视频会议开源的这个分支上，我们也做了很多内容，有的已经合并到1.8版本中，有的合并在1.10版本中。其实我们自己还维护了一个分支没有合并进去，由于将自己的代码合并到开放的分支中需要很多劳动力，所以会在后续逐步完成。

FreeSWITCH支持的标准协议

说到标准协议，FreeSWITCH支持上图中的这些标准协议。

首先FreeSWITCH支持SIP信令，就是音频和视频通话标准的协议，支持各种客户端、终端，目前市面上很多的会议设备都是支持SIP的，可以直接实现互通。

其次我们还做了一个H323的模块，FreeSWITCH本身有两个H323的模块，但都不支持视频，因为有客户需求，就又做了支持视频的模块，这样也就能跟H323的终端进行互通。随着移动互联网的发展，目前各种移动端设备上的APP大多都是支持SIP信令的，可以直接实现互通。

随着WebRTC的发展，很多人开始将其移植到手机客户端上。WebRTC的优点在于不需要自己写媒体层，随着WebRTC的开源带来了很多特性，比如说JitterBuffer、回声消除、降噪等等之类的内容在WebRTC中已经包含，不需要再自己写，虽然不如各种私有化的厂家做的好，因为私有化的厂家可以进行更加极致的优化。但对于一个开源项目来说，WebRTC做的已经足够好了，由于WebRTC只有媒体层没有信令层，所以大家都开始往WebRTC上套各种信令。

值得一提的是RTMP，其实最开始我做的就是RTMP的视频。尽管目前 Flash基本上已经没有人用了，但RTMP协议还是非常好的，目前更广泛应用于直播和推流等。

视频会议的几种实现方式：Mesh、MCU、SFU

视频会议简单来讲有三种方式：Mesh、MCU、SFU。

Mesh是单纯的点对点连接形成的网状结构且不需要服务器，但是这种方式使用的非常少，因为不好控制。

目前比较主流的两种方式，MCU和SFU。

MCU之所以说它比较主流，是因为最开始的视频会议设备基本上都是MCU的。MCU中间有一个服务器，视频客户端与服务器直接通讯，实际上收发都是一路流。视频服务器把所有的流合成一路，即视频融屏。当然音频也会融合，简单起见，我们这里只说视频。视频服务器将视频流融合到一起形成一个画面，分发给所有的终端，所有的终端看到的画面都是一样的，这种情况叫MCU（Multipoint Control Unit），即多点控制单元。

随着WebRTC的出现，很多人开始用SFU（Selective Forward in Unit）。SFU不解码、不融屏，前面说到MCU会对各种画面拼接、融屏，也就需要对视频进行编解码。而SFU只需要把收到的各个客户端发来的视频和音频，有选择的发给不同的人。其好处是不需要占用过多的CPU，但缺点是比较浪费带宽。比如5个人进行通话，其中一方只需要发一路流，转发单元会进行布置，将这一路流复制成多份进行分发，每个人都会收到很多路流，终端所承受的压力会比较大，因为一方的终端需要对另外的4路流进行解码。好处是终端可以自由排列所收到的其它客户端的显示样式，每个人看到的画面都可能是不一样的。

上图是MCU的基本原理图，如图有4个摄像头，各个摄像头把自己的画面上传到MCU，MCU进行缩放、拼接，拼接成一个画面，然后下发。每个终端显示器上显示出来的都是一样的画面。FreeSWITCH内部也是这样实现的，FreeSWITCH内部实现了诸如1、2、3、4等的多个层，以及一个画布（canvas），我们将收到的不同视频解码，再缩放，拼接到画布上，形成一路流，最后分发出去。

画布的样式有多种类型，FreeSWITCH除了支持标准的画布：3×3、4×4、8×8以外，还支持培训班模式：演讲者画面（大）+听众画面（小），以及更多不同的排列形式。

这其中我们做了一个比较关键的优化，就是RTP。众所周知视频流是靠RTP传输，RTP还有一个姊妹协议叫做RTCP，是一个控制协议用来控制RTP，这个协议里有一个东西叫做TMMBR（Temporary Maximum Media Stream Bit Rate Request）。在视频会议中，一般来说大家看到的高清画面有720p或1080p的，而在演讲者模式中，观众的画面通常是比较小的，没有必要上传1080P或720P的画面，浪费1兆或2兆的带宽。这时，FreeSWITCH会发送一条指令-TMMBR，提示不需要高清视频上传，降低带宽上传，这样观众就可以通过低带宽消耗的方式上线，减轻服务器的带宽压力、同时也减轻解码的压力。

我们已经将其应用在我们的视频会议里，效果非常明显。但前提是终端要支持这个协议，在WebRTC中是支持的，这个协议的标准叫RFC 5104。RFC 5104里除了规范TMMBR以外，还规定了一些其它的协议，例如FIR、NACK、PLI，都是与关键帧相关的。在有丢包产生的情况下，FIR是请求一个关键帧，因为解码失败将要出马赛克，请求对方发送一个关键帧，刷新画面。NACK是丢包，其实丢包就涉及到了缓存，就是我所说的Jitter Buffer，Jitter Buffer是在两个通信终端之间，不管是发送端还是接收端，都会有一个Buffer，这个缓冲区发出去的东西，会放到缓冲区里接收，当发生丢包的情况下，发现有一个丢包，就向对方请求重发。这时，对方就看到这个包还在缓冲区，即可从冲缓冲区中取出重发，这种方式叫NACK。PLI是Packet Lost Indication，告诉这一端我丢包了，这个协议负责音视频传输的质量，因为视频传输大多数用的UDP的协议是不可靠的，所以在发生丢包的情况下再做比较多一些补偿。

我们还做了一些其它的优化，在大规模视频会议中，几十个人甚至上百人参与，对于服务器的解码压力会比较大。而且同时在一个屏上显示几百个人是没意义的，因为太小根本看不清观众表情，所以一般在参会人数比较多的情况下，就直接展示几个或者几十个人，太多了就不展示，不展示的部分也就没有必要解码，不需要浪费服务器的处理能力。但观众还是需要轮番展示一下的，所以我们还做了一个多人轮循展示，例如现在开始看这10个人，下一次我再看另外10个人，然后做一个定时器进行轮循，让每个人都有出镜的机会。当然由于关键帧的原因，展示出来的时候，就需要解码，这时不一定正好有个关键帧过来，所以需要提前两秒开启解码，然后等展示到它的时候，一般这个关键帧就到了，因为每次展示的同时也会向对方要关键帧，这样的话正好能展示出来，不至于黑屏。还有一些我们在视频会议的过程中遇到很多坑，例如NACK请求太多，有时候由于好多终端的网络都不好，然后都过来请求NACk丢包，如果是发现这个NACK请求太多，我们就直接发关键帧，不理会丢包情况。

还有就是限制FIR请求的频率，FIR就是我们说的关键帧请求，刷新关键帧，当终端在网络条件不好的情况下请求一个关键帧，若有10个终端都请求关键帧，若一秒钟之内产生10个关键帧，带宽就会被撑爆或者视频画面会非常的模糊，因为满足不了这么多关键帧的请求，所以我们做了一些算法，其实这也是一些基本的算法，限制关键帧的请求。例如可以设置两秒或者三秒，那在这两秒或者三秒之内，只产生两个关键帧，即第一个请求和最后一个请求会产生关键帧，其他的都忽略，这样的情况下才会保护带宽，当然对方可能会有短暂的花屏，但是没关系，然后两秒钟之内就已经清晰了，因为毕竟其网络状态不好自身是可以忍受的，当然如果是网络状态都好的终端呢，他也不会有影响。

另外，不同的编码有不同的编码器， FreeSWITCH支持不同的编码，由于历史原因，Chrome支持vp8，苹果的浏览器只支持H.264,不能实现互通，然后最开始的WebRTC也不能互通，当然最近几年可以了，Chrome也支持H.264了，其他的浏览器也支持vp8了，所以说FreeSWITCH从最开始就支持多种编码，然后在同一个会议里，不同编码的会议，用不同的编码器即可。

还有情况不同的终端，可能这些做私有终端、私有通信的没有这种困扰，因为终端都是他自己的，规定用什么编码就用什么编码，但是在开源领域，需要面对各种各样的客户端，例如军队的项目，他们好多设备还是H.263的，不能被替换，我们就只能去适配H.263，H.263不支持720p的分辨率，它只支持CIF分辨率的，CIF即不是16:9也不是4:3，所以需要我们单独分一个编码器。等等之类的情况，想要支持的终端的型号越多需要做的就越多。

早期的我们也做了一些优化，降分辨率、降帧率，发现有终端使用flash是我们处理不了的，那么我们就降分辨率，把分辨率降低一半，然后降帧，原先30帧降成15帧。现在有了更好的技术叫SVC，SVC就是在一个编码器里出多个分辨率和多个帧率，当然对CPU还是有代价的，它编出来之后可以有选择的去分出去，其实FreeSWITCH有一个模块叫mod_openh264，使用的是思科开源的编解码器，支持SVC，但目前我们还没有使用，只是用了它比较简单的编解码的功能，我们在FreeSWITCH内部使用的，另外一个就是内部的libx264，它是在FFmpeg自带的。

在视频会议里边我们经常遇到的还有一个就是双流，传统的视频会议设备，H.323的设备，一般支持的协议叫H.239，它可以在一个通话里支持两个流，一个流是演讲者的视频，另外一个就是PPT，两个流可以上到MCU，大家可以看到，甚至对方也可以放两个电视或者投影仪，一个投影仪展示演讲者的视频，另一个投影仪展示PPT。

SIP设备也支持双流，SIP设备的双流叫BFCP，全称是Binary Floor Control Protocol。演讲者会做一些控制，H.323的双流我们没有做，只做了简单的对接，由于对接的设备比较少，能通即可。对于SIP协议的双流，我们现在还没有开源，也是BFCP的。我们直接在SIP的模块中挟持了SDP，因为在SDP里边会有两个视频流，挟持到以后处理生成一路新的呼叫（一个假的呼叫），FreeSWITCH在收到一路呼叫时，就看到他是一个双流的呼叫，然后就生出两个呼叫，这样的话两个呼叫会同时调到会议里边，会议的代码不需要改。对会议来讲是来了两个呼叫，但是对FreeSWITCH来讲是一路呼叫，这样就可以支持双流了。

另外在WebRTC中，双流有一个叫Simlcast，它也可以在一个SDP里边看多个流，由于Simlcast早期不稳定，有很多问题，现在我们利用Simlcast只是做了一些实验，还没有具体详细的代码，我们只是比较简单粗暴的，直接在浏览器里发起两路呼叫，一个呼叫是演讲者的这个视频，另外一个呼叫是共享桌面，因为在浏览器里发起WebRTC呼叫时，可以直接选视频源是摄像头还是屏幕或者是共享某个应用程序，形成了这种双流。同样到了FreeSWITCH，它还是作为两路流，作为两个呼叫进到会议中。

对于上面提到的SFU，FreeSWITCH是可以实现SFU的，其实我们也做了很多的尝试，但是SFU比较复杂，需要控制很多路呼叫，未来FreeSWITCH的核心是要支持多路流，但是目前实现SFU的计划还未提上日程，另外一个原因也是由于市面上很多做SFU的产品，并且都比较成熟了，例如Jitsi、Kurento、Janus都有SFU的实现，如果需要的话，可以搭配FreeSWITCH进行实现。

当视频会议的规模比较大时，就需要级联，因为一台服务器支撑不下。FreeSWITCH的视频会议在实验室测试一台服务器可以支撑400路720p的视频流，根据具体的应用场景选择服务器的规格是32核或64核，当然我们在开大会的场景下，不会把所有的人都显示出来，只把展示出来的人编解码，就是上面提到的优化不解码，这样可以只编码一路流下发，所以对CPU的压力不大。其实我们在实验室里做到400路流，但是给客户上线的是一台服务器支撑100路终端，最大应该能上到200路。但是应用场景是需要800路客户终端，那我们就做了级联。

级联存在一个问题，我们称之为“看对眼”，就是当两个MCU级联时，例如1、2、3在一个MCU上，5、6、7在另外一个MCU上，当MCU合成出的画面进入到另外一个画面的时候，它就会把你的画面返回来，这样这中间就有一个无限循环的画面，当然下图的动图就体现的比较直观。

在做桌面共享的时候肯定对上图这个界面比较熟悉了。

其实Google上能搜出很多类似的情况，这就是我们收到的视频又作为视频源发出去了，这种情况就称为看对眼。视频会议在两个MCU进行级联的情况下就会出现这种情况。那么如何解决呢？

FreeSWITCH实现了一个功能叫做多画布，如上图的应用场景，当一个人开始演讲时，就将其当做主会场，放在画布1上。所有的与会者都需要看到主会场，同时演讲者需要监督其它与会者学习，就需要看到其它与会者的画面，我们把与会者的画面都放在第2个画布上，主会场人员就可以看到分会场的与会者情况。

甚至FreeSWITCH还有一个Super Canvas——超级画布，主要用来做监控的，无论会议里有多少个画布，都可以一目了然的看到。这样，后台管理人员做会议控制的时候，就可以很方便地看到整个会议的场景。通过这种方式，我们就解决了这个“看对眼”的问题，这样两个MCU就可以级联了，例如上行MCU永远放在画布2上，下行MCU永远在画布1上，这样就可以它们区分开。

上图是一个级联的示意图，Master是主服务器，下边有很多FreeSWITCH的从服务器，下行画面永远是在第1张画布上，上行画面的永远是在第2张画布上，反之也可以。这样的话就可以随时切换，查看上行的情况，各个与会者也都可以看到主会场。有时在开会的过程中，为了防止与会者只看到主会场而感到孤独，这时我们就会把第2张画布的画面也推下去，这样所有人都看到其它的与会者。甚至在开会的过程中要交流，例如举手发言，这时也可以替换掉主会场的画面。级联的基本原理就是这样，但实际控制还是比较复杂的。

值得一提的是，FreeSWITCH与现在的一些视频会议不同，比如某些会议可以简单的支持几百人规模的会议，将演讲者画面推到一个流媒体服务器上，但是演讲者是看不到与会者的。这是实际上是一种直播的模式，与会者收到的流都是单向流，只有下行的流。

在一些直播场景中，交流互动即直播连麦。由于参与用户规模比较大，例如十万人的直播场景，当主播跟观众想要进行互动的时候，就需要把这个观众的层级提升，提升到主播的阶层，这时我们才可以把他的画面广播出去。这种应用场景与视频会议在实现原理上基本是一样的，不过FreeSWITCH的会议自始至终都是双向流的。

有了这种方式以后， FreeSWITCH就可以跟其它的MCU进行级联。另外有的单位已经有MCU了， FreeSWITCH又有多个画布，就可以把上行和下行的区分在不同的画布上。例如图中左边两个1、2是FreeSWITCH的用户，右边两个手机客户端上3、4是其它MCU的用户，上行以后在其它MCU上进行融屏后下发即可。

与其它会议系统对接

FreeSWITCH除了与其它MCU对接、级联外，还做了一些优化。

因为FreeSWITCH是开源的，如果要与其它的视频会议系统对接，就需要集成其它视频会议的SDK。比如我们可以跟腾讯会议对接（目前已经接通了音频，视频还没有接），TRTC提供多平台的SDK，我们写了一个模块将其放到FreeSWITCH里，FreeSWITCH就可以与它进行通信。通过PSTN我们可使用电话拨号接入到FreeSWITCH中，也就可以直接接入到腾讯会议中，FreeSWITCH可以当做网关一样使用。当然PSTN现在还不支持视频，只支持音频。

另外一个是Agora的SDK，我们早在很多年前就集成了Agora的SDK，音频和视频都可以接通。

以Agora为例，我们在FreeSWITCH中写了一个模块叫mod_agrtc，这样就可以实现与Agora的互通。Agora与WebRTC类似，只有媒体层的SDK没有信令层，因此就需要自己实现一个信令的服务。当然一般公司会做自己的APP，需要进行注册、鉴权等，已经有信令服务，那么只需要调用FreeSWITCH的API，就可以控制发起呼叫、录音等，实现互联互通。但有的客户不想自己写信令服务，或是自己的信令服务难以扩展。所以我们也写了一个基于WebRTC的信令服务，在移动端集成Agora的SDK，FreeSWITCH里集成了Linux的SDK，即可实现互通。

这其中存在一个问题，无论是Agora还是 TRTC，由于早期的SDK是针对客户端的，所以只支持一个客户端，也就是一个SDK只支持一路通话。于是我们又做了一个服务 — IPC，有几个通话就在FreeSWITCH中创建几个进程，这样就可以实现与FreeSWITCH的互通。

微信小程序解决方案

说到微信小程序，我们再讲一下Flash。其实对于Flash的支持很早就已经在FreeSWITCH中实现，FreeSWITCH有个模块叫mod_rtmp，RTMP协议已经实现了。因为微信小程序使用了RTMP的协议，我们最开始做微信小程序的时候，本来就是想在RTMP的基础上进行扩展实现微信小程序的支持，但实际上并非如此，原来的Flash只需要一个socket和信令，就可以进行音视频的通信，但是微信小程序不行。

微信小程序中提供了两个组件，Live Publisher以及Live Player，是推流与拉流的概念，用RTMP的流可以收和发。于是我们就引入了SRS的服务（SRS也是一个开源软件，主要用于直播平台），起了个名叫mod_weixin。FreeSWITCH可以推流到SRS上，通过小程序来拉取，反之微信小程序可以推流到SRS上，FreeSWITCH再拉取。这样就实现了一个双向的通信。

由于RTMP没有信令，所以我们又实现了Websocket的信令，小程序还是通过Websocket连到FreeSWITCH，这样才能控制通话的建立和连接。

ASR/TTS

FreeSWITCH还支持ASR/TTS，当然并不是原生的支持，而是通过调用一些第三方的SDK实现，这样就可以实现智能控制，甚至做自动会议记录、自动翻译等等。

NAT穿越

在公网上实现视频会议，不可避免的涉及到NAT穿越问题。对于NAT穿越，WebRTC已经做得很好了，比如ICE方式。FreeSWITCH当前已经支持ICE，在ICE打不通的时候，也可以用Stun/TURN服务器进行打通。

还有一些应用如银行，由于情况特殊不能开太多端口。而基于FreeSWITCH的通信每一路通话都要求多个RTP的端口。所以可以采用VPN的方式，连接到公网的服务器上，这样只需要一个UDP的端口即可实现。

针对大规模的视频会议，我们使用了iptables。例如我们在北京和上海都有服务器，就可以在上海的服务器上做一个iptables，然后将所有的流量全部转化到北京的服务器，这样客户端就可以实现就近接入。当然对于一些比较灵活的应用，就需要通过设计相应的应用程序来控制如何调用这些iptables做转发。

除此之外，我们也尝试了腾讯云的CLB（负载均衡）。实际上腾讯云的负载均衡，可以直接提供一个云的负载均衡IP，然后转发到后端的服务上。

下一步我们计划尝试使用阿里的LVS。

在目前情况下，加上前面提及的会议室级联技术，其实已经可以实现相对比较大规模的视频会议。

4G/5G

下一步就是4G/5G，我们其实已经做了很多的尝试。目前直接用手机的4G发视频呼叫的情况可能还比较少，但在业界一些客服系统中已经开始使用，部分客户可以直接通过电话的方式，使用4G视频呼叫到呼叫中心，进行信息交互。相信随着未来5G的发展，通信技术与能力也会愈加强大。

FreeSWITCH社区官网：https://www.freeswitch.org.cn 欢迎大家关注、一起交流，未来我们也会将开源进行到底。另外，考虑到FreeSWITCH涉及面可能会太窄，我们就做了一个RTS的社区—Real-Time Solutions，未来也会把对FreeSWITCH扩展的一些代码开源，放入其中。当然最终的目标是直接放到上游的FreeSWITCH当中，但因为需要经过各种的代码审查，接收可能会比较慢，所以会先存放在这个仓库中，等待时机成熟再开源到FreeSWITCH上游。如果大家有条件、有能力的话也非常欢迎一起参与进来。