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，简单了解一下它的历史。

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 支持 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，这样才能控制通话的建立和连接。

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

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

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

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

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

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

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

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

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