文 / 杜金房
整理 / LiveVideoStack
大家好，我是杜金房，此次分享和双向通讯服务器FreeSWITCH以及WebRTC有关。首先我会为大家简单介绍FreeSWITCH，鉴于FreeSWITCH主要用于通信领域，我也会介绍WebRTC并阐述FreeSWITCH与WebRTC的关系，同时结合FreeSWITCH的其他功能和使用场景与其功能以及所使用的多媒体库，进一步探索AI技术加持下FreeSWITCH的未来发展。
1. FreeSWITCH简介
FreeSWITCH是一套开源的，集成强大多媒体引擎的软交换系统。FreeSWITCH主要基于C语言编写，集成的众多方便灵活的开发接口使其具有出色的互联互通的能力，不仅兼容各种手机电话等终端设备并与各类软件相互对接，也提供了对多种应用场景如电话通信、视频会议的支持。根据FreeSWITCH官方给出的数据，FreeSWITCH已成功被应用于通信运营、在线教育、视频会议与设备互联网关等。
说到开源，想必大家不会对上图展示的这些Logo感到陌生，包括像Linux、Android这样的开源操作系统，MySQL等开源数据库以及APACHE这样的开源Web服务器。而通信领域也有两个较具有代表性的开源软件：Asterisk与这次重点介绍的FreeSWITCH。
2. 通信发展
其实在诞生初期FreeSWITCH主要被用来解决使用RJ11接口，基于电路交换原理实现的模拟电话机等传统电话通信问题；随着数字技术的发展，使用RJ45接口/Wi-Fi，基于分组交换的IP通信与在此基础上进一步升级的视频电话逐渐普及，成为过去十年人们沟通交流所使用最为频繁的工具；同时由于互联网技术的突飞猛进，越来越多的人有机会享用海量网络资源，基于互联网传输实现的各种实时通讯APP应运而生。
从古代的烽火台与语言交流到近现代的模拟电话，再到现如今人们再熟悉不过的数字电话，通信的进步可以说与社会生产力进步与人类文明发展密不可分。传统的模拟电话通过传输模拟信号实现远距离声音传输，而随着传输距离的增大与传输条件的变化，模拟信号会在传输过程中遭受明显衰减，这就需要安装在接收端的信号放大器处理接收到的模拟信号从而使其中的关键信息更容易被获取；但这样做并非完美，放大声音的同时如噪音、呼吸声等环境杂音也会被放大，间接导致有效信号比率降低，直接带来的影响便是远距离的通话双方无法清晰而准确地拾取对方所要表达的关键信息。
为了满足远距离通信数据传输的有效，数字通讯技术应运而生。数字通讯可实现在进行远距离传输的同时几乎不损失通话质量，从传统的电话机到大家使用的第一款GSM手机再到现在的智能手机，可以说数字通讯极大改善了人们远距离沟通交流的方式。与此同时，从最早的拨号电话、GSM手机到3G、4G以至于未来的5G，通信技术的发展也可谓突飞猛进。通信技术的迭代也带来了互联网技术的飞跃。例如在4G/LTE诞生之前，由于通信所使用的网络通道与网络传输所使用的并不相同，用户无法在打电话的同时访问互联网；而对4G/LTE而言，包括语音电话与访问互联网在内的所有通讯活动都通过IP网络传输数据，这就避免了打电话与访问互联网的冲突。
FreeSWITCH是一个开源的软交换系统，所谓的软交换是指不考虑终端类型，所有话机都可以通过FreeSWITCH与其他设备互联互通。上图中展示的终端除了有电话、手机，还有监控摄像头、视频电话甚至RTMP、Flash等等。FreeSWITCH的特点就是可对接任何设备，例如通过浏览器可实现WebRTC与FreeSWITCH之间的通信，从而允许用户通过浏览器拨打电话。
3. WebRTC风生水起
早期实现浏览器拨打电话一般需要ActiveX技术的辅助，这是IE上的一个插件系统；与此类似的还有Flash，同样可以实现互联网电话的功能，但由于Flash的功耗过大，支持Flash的移动端设备越来越少，Flash也就此没落；Flash日渐式微而WebRTC风生水起，WebRTC可以说完美解决了Web端的双向通讯活动问题。最早的Web都是通过从服务器加载网页实现单向通讯，随着WebRTC的诞生，诸如视频直播等双向通讯活动也成为可能，现在支持WebRTC的浏览器包括Chrome、FireFox、Opera与Edge等。
WebRTC并非一项全新的技术而是多种技术的加成结果，包括音视频编解码技术、用于避免通话回声的回声消除技术、降噪技术、流媒体传输技术、NAT穿透技术，当然还有用户普遍关心的安全技术等等，较为典型的安全解决方案是HTTPS/WSS，其中的HTTPS超文本传输安全协议用于安全传输数据并验证数据来源的可靠，而WSS（WebSocket）则是HTTP基础上的升级，借助双向的Socket通信解决了基于UDP并使用RTP传输协议交换数据的安全性问题。
WebRTC不仅被用于Web，同样也被用于移动端尤其是各种APP，WebRTC在移动端的普及也让音视频编解码、回声消除等技术在移动端大放异彩。我们知道WebRTC标准的最早提出者是Google，下一代WebRTC标准是WebRTC 2.0，又称ORTC（Object RTC）。对比ORTC与WebRTC，二者主要在媒体的描述方式上有较为明显的差别。WebRTC 1.0的描述基于SDP，通过文本描述媒体特性；而ORTC则直接使用一个对象描述媒体。
需要注意的是，WebRTC仅是一个媒体层标准而并没有规定信令，传输媒体至客户端需要信令来确定数据的传输路径与终端。以Chrome浏览器为例，其中被称为GetUserMedia 的API被用于获取用户媒体，所产生的SDP描述了相关音频与视频文件。具体过程是：首先浏览器发送SDP的同时也会获取一个SDP，此发送的SDP会从GetUserMedia端获得相应视频，信令的作用是实现SDP的交换。WebRTC解决了点对点网络连接与通信传输PeerConnection面临的端口匹配、编解码等问题。信令主要用于交换SDP，PeerConnection点对点连接与DataChannel数据信道用于传输媒体。
SIP是通信领域中的一个标准信令，想必在通信运营商工作的朋友不会对此感到陌生。上图展示了SIP信令的具体流程：假设左侧A、右侧B两位用户进行通信活动，A会给B发送INVITE，INVITE中包含A端主叫号码与B端被叫号码，同时INVITE里包括了用于描述音视频等媒体信息的SDP；当INVITE发送至B端后，B端会给A端回复100 Trying表示成功接收INVITE，同时回复180 Ringing表示B端振铃并给A端反馈回铃声让A端用户知道B端已接收到通话请求；当B端用户拿起电话接通时，B端会发送200 OK，切断回铃声以告知A端用户通话连接成功，双方正式开始进行通话；图中的ACK全称Acknowledgement，INVITE、200 OK、ACK可视为一组三次握手过程，同时也意味着成功建立了媒体数据传输；RTP Data代表双方进行音视频通话时数据的交换，一旦在通信过程中有一方（B端）挂断电话，主动挂断的一方（B端）会发送BYE至另一方（A方）以告知通话结束，同时被挂断一方（A端）向对方（B端）发送200 OK确认通话挂断，通话活动结束。SIP信令与HTTP相比在包括文本消息等方面都较为相似，相对于SIP，HTTP只通过一个Get请求就可得到200 OK。
4. FreeSWITCH与WebRTC
FreeSWITCH实现了两种信令：基于现有标准的SIP与基于WebSocket和JSON的非标准信令Verto。在绝大多数情况下，浏览器端的数据主要通过UDP和TCP传输，SIP不直接传输数据而是承载于UDP或TCP之上；加之虽然UDP的适用范围更广但传输较为麻烦，于是由HTTP基础上升级而来的WebSocket协议成为了另一种选择。FreeSWITCH中有在WebSocket基础上加入Web协议实现的SIP over WebSocket，但由于SIP主要是为传统通话设计，对于电脑与移动互联网设备来说过于臃肿；随后FreeSWITCH又出现了一种被称为Verto的非标准信令，主要基于WebSocket，信令格式为Json。无论使用以上两种信令中的哪一种作为信令，成功进行SDP交换之后FreeSWITCH就可以实现和Chrome的通信了。
FreeSWITCH可以实现万物互联，以至于我们探索了基于FreeSWITCH实现的微信小程序之间的通信并成功构建了双向RTMP通信。我们在FreeSWITCH内部写入了一个模块便于所有设备与FreeSWITCH建立通信，从而实现如果有任何一方接入通信至FreeSWITCH，与FreeSWITCH连接的其他所有设备都可同步进行通信。例如通过微信你可以看到家中IP摄像头的监控画面，也可即时加入视频会议；视频会议不仅可以通过专业设备举行，也可以通过Chrome等浏览器传输，这种互联互通的特性可以说是FreeSWITCH的最明显特性。
当然不同的厂商为了追求利益的最大化，都会努力实现开源的FreeSWITCH对全平台的兼容。除了我们之前分享的SIP信令，FreeSWITCH中还有一种被称为H.323的信令，H.323信令主要被用于早期的IP话机与视频会议设备，而由于SIP的互通性能更出色，现在绝大多数设备都放弃了对H.323的支持。H.323协议基于二进制而SIP则是基于文本，相对于前者具有更好的可定制性。Flash与RTMP都是Adobe提出的协议，对比二者RTMP的综合性能更加优秀。包括现在的许多互联网直播推流拉流、微信小程序等都因为其稳定可靠而使用RTMP协议，相对于WebRTC，RTMP应用也较为方便。在这里我们并不是说某一种协议拥有绝对优势，我们应当按照实际需求与产品特性选择最适合的协议。
5. 其他功能与使用场景
FreeSWITCH可被用于实现多屏视频会议，甚至可以实现8x8的画面部署。
无论是使用FreeSWITCH还是传统的WebRTC，实现视频会议都离不开以下三种控制策略：Mesh、MCU与SFU。Mesh是单纯的点对点连接形成的网状结构且不需要服务器，由于每个节点都需编码传输多路，非常浪费带宽与运算资源；MCU则被FreeSWITCH所采用，也就是通过中间的多点控制单元收集各方传来的音视频数据并发送至FreeSWITCH，由FreeSWITCH将多路音视频信号整理合成为一路包含所有画面的音视频流并传输给每一个用户，每个节点仅与多点控制单元进行数据交换，所消耗的带宽与运算资源也会明显减少；当然这样做相当于是把包括编解码在内的大量运算任务交给FreeSWITCH完成，这就要求FreeSWITCH集成CPU与足够的带宽资源。
SFU也就是选择性转发单元是第三种实现视频会议的方式。如上图最右侧展示的那样，如果有五方进行视频会议，首先所有人都需要将自己这段的音视频信号传输至中间的选择性转发单元，SFU会按照会议需求选择性转发信号至每一个用户。相对于MCU，不处理编解码任务的SFU节省了一部分CPU运算资源，但代价是带宽消耗明显提高，总而言之，实现FreeSWITCH的前提是使用MCU。
如果具体来说MCU在FreeSWITCH中的作用便是如上图展示的那样：黑色箭头代表下发，红色箭头代表上行；假设这里有四台设备分别输入的画面为1、2、3、4，现在我们将这四路画面传输至FreeSwitch的MCU设备，经过MCU的缩放、拼接、合成一路等一系列处理，我们得到了一个由四方画面拼接而成的会议画面；此时每个用户看到的画面都是视频融屏后的结果，同时看到四个画面且完全一致。
多画布是FreeSWITCH的另一项功能，此功能多用于大型会议现场。有些应用场景需要主讲人与观众看到两个不同的画面，例如讲师看到的是观众的反应而观众则看到的是演示文稿或者会场实况，这就需要构建两个画布或多个画布，按照每位观看者的需求向其投送需要的画面。
集群也是FreeSWITCH上较为常用的功能，实现起来也比较复杂。集群多用于扩展会议规模，当然这需要多台服务器的集中处理。
FreeSWITCH也支持非常丰富的多媒体编码，包括音频领域的PCMA、PCMU，浏览器中常用且适应性较的OPUS，当然还有常见的H.264、H.263、VP8、VP9等视频编码标准。
传统语音电话领域也有借助FreeSWITCH的力量提升用户体验的案例，如互动式语音应答IVR。上图展示的就是一个较为趣味的场景，通过简单的编程定义每个操作所触发的活动，从而实现互动语音应答与响应。
除了前面介绍的应用，FreeSWITCH在其他方面的应用如上图展示的那样，可以说FreeSWITCH的应用范围十分广泛。
6. FreeSWITCH所使用的多媒体库
FreeSWITCH可以用到的多媒体库有用于处理各种音视频文件的Libsndfile、处理VP8、VP9的libvpx、处理图像的libpng与Imagemagick，当然还有处理各种音视频文件的FFmpeg与用于计算机视觉的OpenCV。
7. AI赋能
尽管FreeSWITCH本身不能实现AI，但这并不妨碍AI为FreeSWITCH处理音视频赋能。FreeSWITCH内部有一些可用于语音识别/语音文本互转的ASR/TTS模块，借助这些模块FreeSWITCH可把收集到的音频信号传至多轮人机对话系统。除此之外，人脸识别、ChromaKey也是较为常见的应用方向。
其中ChromaKey就是虚拟演播室，通过绿幕技术替换主播环境的背景等元素，极大丰富了产品视听体验。
当然这些功能的实现离不开Media Bug媒体监听。例如Alice与Bob通话时Carl端通过类似于三通的路径监听二者通话，并在需要时加入ChromeKey等处理。
8. 总结与展望
总结以上分享内容，FreeSWITCH是一个开源的软交换平台，具有模块化结构，实现了对包括WebRTC在内的各种互联互通的良好支持与新特性的部署；同时也易与各种AI平台交互对接，并能作为处理多媒体的服务器使用。借助FreeSWITCH，我们希望为相关行业带来更加出色的多媒体传输服务，实现通联世界平等沟通的美好愿景。
————————————————
版权声明：本文为CSDN博主「LiveVideoStack_」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/88802333
「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实践技术文章，在这里与音视频领域一流工程师交流切磋。
