FreeSwitch

    直到几年前，电话还是一座由大公司严格把守的带围墙的堡垒，几乎没有人能完全理解它是如何运作的。通过参加内部技术研讨会和内部学校，你有机会获得这些深奥的知识，甚至这些知识也仅限于你要工作的系统部分（中央办公室、最后一英里、PBX等）。承载和路由呼叫的基础设施以及应答和管理呼叫的应用程序都是临时的、僵化的、彼此不兼容的，并且需要大量的投资。



    两次革命彻底摧毁了旧世界。第一次是VoIP电话革命，它带来了一个开放协议（SIP），首先革新的是应用程序/PBX领域，然后是基础设施领域。原有体系中，有一个专用的PBX，它只能通过更换同一家公司生产的内部硬件卡来扩展，只提供自己的类型和型号的硬件电话。变革后，它被标准PC架构的标准服务器取代，使用现成的扩展卡，能够支持任何类型的标准兼容电话。紧接着，SIP从下到上爬到了大型电信基础设施的核心。今天，包括大型电信公司和运营商在内的所有电信基础设施都在运行SIP协议的某些版本。



    第二次革命，现在正在进行，还需要几年才能完成并取得成果，它就是WebRTC。这是一个误导性很强的名字，WebRTC根本不需要web页面和浏览器。WebRTC是一系列用于通信终端间加密互联的标准。只不过这些WebRTC标准正好首先在浏览器中实现而已。与此同时，它已成为物联网的主流通信方式，从智能手机应用到汽车、电梯、商店出纳和销售点。



    如今，我们有可能建立一个比传统的语音、视频和会议服务更好的通信系统，并以相对低廉的成本提供现高级的功能。Freeswitch的设计就是为了让所有这些变得更简单，我们将仔细研究它的架构，以便更好地理解它是如何工作的。



    如果你不能一下子掌握所有内容，不必担心。学习需要时间，尤其是RTC和VoIP。事实上，我们建议您反复阅读这一章的内容。第一次通读时尽可能多地吸收，然后在读完第6章XML拨号方案后再回头。你会惊讶于你对FreeSWITCH的理解有多大的提升。然后，在读过第10章（拨号方案、目录、通过XML_CURL和脚本实现一切）之后，回来第三次浏览它，您将牢固掌握FreeSWITCH的概念。给自己一些时间去消化这些概念，您将成为熟练的FreeSWITCH管理员。



    今天，我们生活在多种实时通信技术的生态系统中，它们同时共存：电话系统（如电话交换机和PBX）、传统的模拟电话（POTS线路或普通的老式电话服务）、运营商运营的传统电话网（PSTN或公共交换电话网）、移动电话（CDMA、GSM、LTE等）、传真、WebRTC、智能手机应用程序、VoIP电话和企业系统。



    FreeSWITCH就位于这些生态系统的中心：它连接并接受来自所有这些技术的连接，将它们桥接并混合在一起，它为用户提供交互应用和服务，无论他们的终端是什么类型的。FreeSwitch能够连接到外部数据服务、遗留的内部系统、计算机程序和业务程序等等。FreeSWITCH是跨平台的，可以运行在Linux、Windows、Mac OS X、BSD和Solaris上。我们有很多硬件可以选择，从大型服务器到Raspberry Pi都支持。因此，您可以在您的笔记本上开发，然后把它部署到数据中心或嵌入式设备上。第2章详细描述了FreeSWITCH的安装部署过程。

    FreeSWITCH的设计目标是提供一个模块化的可扩展的系统，围绕一个稳定的交换内核，为开发人员添加和控制系统提供一个强大的接口。Freeswitch中的各种元素彼此独立，除了“Freeswitch API”中提供的内容外，对其他模块的工作方式没有太多的了解。Freeswitch的功能可以通过可加载模块进行扩展，这些模块将特定功能或外部技术绑定到核心中。



    在FreeSWITCH中，有许多不同类型的模块围绕着内核，就像一个机器人的大脑连接着许多传感器和接口一样。这些模块的类型列表如下：

    下图体现了FreeSWITCH的架构和FreeSWITCH的内核与外围模块的关系：









    通过组合各种功能模块，可以把FreeSwitch配置为IP电话、POTS线路、WebRTC和基于IP的电话服务。它还可以转换音频格式，自定义交互式语音菜单（IVR）系统。还可以从另一台计算机控制FreeSwitch服务器。接下来，我们介绍两个重要的模块。

    Sofia-SIP (http://sofia-sip.sourceforge.net)是一个开源项目，最早由诺基亚开发，它提供会议初始化协议（SIP）的接口实现。Freeswitch开发人员对它进行了大量的开发和修复，进一步增强了其健壮性和特性。在FreeSWITCH中我们使用自己的定制版本库(/usr/src/freeswitch/libs/sofia-sip)，这是通过一个名为mod_sofia的模块实现的。这个模块注册FreeSwitch所需的所有必要钩子，以生成终端模块，它将FreeSwitch的原生结构转换为Sofia SIP结构，反之亦然。配置信息取自freeswitch配置文件，这使mod_sofia可以加载用户定义的首选项和连接详细信息。它允许FreeSwitch接受来自SIP电话和设备的注册，可以向其他SIP服务器（如服务提供商）注册，发送通知，并为话机设备提供服务（如亮灯和语音邮件服务）。

    首先，SIP话机通过网络向FreeSWITCH发送一条建立通话的消息（mod_sofia时刻监听这类消息）。收到消息后，mod_sofia反向解析相关细节，建立一个内核能够理解的抽象呼叫会话数据结构实例，并将它传递给FreeSWITCH的内核状态机。然后状态机迁移到ROUTING状态（意味着正在寻找目的地）。



    内核的下一步是根据呼叫终端的配置数据确定拨号方案模块。XML拨号方案模块是缺省的和使用最广泛的模块。这个模块的设计逻辑是从FreeSWITCH内存中的XML树查找一系列指令集。XML拨号方案模块会用正则表达式匹配来解析一系列的XML对象。



    当我们正尝试呼叫2001时，会在XML节点中寻找一个destination_number字段与2001相匹配的分机。此外，我们要记住拨号方案并没有限定只能匹配一个分机。一个呼叫在拨号方案中允许有多个匹配，在第6章，XML 拨号方案主题里，您将会得到分机这个术语的扩展定义。XML拨号方案模块会为呼叫建立一个TODO列表。每个匹配的分机将它的操作要求添加到呼叫的TODO列表中。



    假设FreeSWITCH至少找到一个条件匹配的分机，XML拨号方案模块将会向会话对象中插入指令，其中包含尝试呼叫2001所需要的信息（建立这个呼叫的TODO列表）。一旦指令就绪，呼叫会议的状态会从ROUTING迁移到EXECUTE，内核将钻取列表，并逐个执行ROUTING状态下所堆积的指令。这就是API发挥作用的地方。



    每条指令都以一个命名application形式添加到会话中，可以向application传递一个data参数数据。在本例中，我们将会用到bridge app。这个app的作用是创建一个新的会话，建立外呼连接，然后把两个会话连接在一起进行音频数据交换。我们将给bridge提供一个参数：user/2001，这是生成内部注册分机呼叫电话对象的最简单方式。针对2001的拨号方案条目，看起来是这样的：

    这个分机被命名为example，它有一个单一的匹配条件。如果条件匹配成功，它需要执行一条单一的app。可以理解为：如果主叫方拨打2001，那么将在主叫方与终端间建立一条连接



    一旦指令在会话的TODO列表中插入完毕，会话的状态立刻迁移到EXECUTE，FreeSWITCH内核将开始使用所搜集到的数据执行所需的操作。它首先解析列表，发现它必须对user/2001执行bridge；接下来，查找bridge app，并将参数user/2001传递给它。这将导致FreeSWITCH内核按所需类型创建一个新的外呼会话（也就是一路呼叫）。我们假定2001分机的用户用一个SIP电话注册到FreeSWITCH ，那么user/2001将被解析为一个SIP拨号串，这个拨号串将被传递给mod_sofia，请求建立一个外呼会话（指向2001的SIP话机）。



    如果新的会话建立成功，那么FreeSWITCH内核中将会存在两个会话：新建会话和原始会话（主叫侧建立的会话）。Bridge app将会接管这两个会话，将对它们调用bridge函数。在被叫接听后，bridge调用将使音频和/或视频流在双向间流动。如果用户不能应答或正忙，会触发超时（也就是呼叫失败），那么会给主叫话机回传一条失败消息。如果一个电话无人应答或分机占线，拨号方案中可以有许多种不同的响应，其中包括呼叫转接或语音信箱。



    FreeSWITCH继承了SIP的所有复杂性，并将其简化为一个公共的(内部的)接口。然后通过允许我们使用拨号方案中的一条指令将2000分机的电话连接到2001分机的电话，进一步降低了复杂性。如果我们还想让2001分机能够呼叫2000分机，我们可以在拨号方案中添加另一个条目:

    在这个场景中，终端模块（mod_sofia）把呼入的SIP呼叫转换为FreeSWITCH会话，而拨号方案模块（mod_dialplan_xml）把XML转换为分机。然后，bridge app（由mod_dptools模块提供）把复杂的外呼和连接媒体流的过程，变成了一个简单的应用/数据对。拨号方案模块和app模块接口都是围绕FreeSWITCH会话设计的。抽象不仅让用户层的工作变得更容易，而且还简化了app和拨号方案的设计，因为它可以使呼叫过程中涉及的终端技术细节透明化。正是由于这种抽象技术，当明天我们为三维全息通信网络编写一个新的终端模块时，我们将能够重用所有的app模块和拨号方案模块。对于FreeSWITCH内核和其它所有FreeSWITCH模块来说，仅是多了一种全息三维呼叫方式，它也仅仅是一个标准的会话抽象而已。您可能希望使用终端的协议提供的一些特定数据。比如说在SIP协议中，包含了几个特定的头域或其它一些有趣的数据，您可能希望获取这些特别的信息。我们通过向通道（channel，会话结构中与终端交互的部分）添加变量来解决这个问题。使用通道变量，mod_sofia可以创建在SIP数据中遇到的任意值，您可以在拨号方案或app中通过变量名检索这些值。这些最初是底层SIP消息的特定（任意）部分，然而，FreeSWITCH内核只是将它们视为内核可以忽略的普通通道变量。此外，还有一些特殊的保留通道变量，它们可以以许多有用的方式影响FreeSWITCH的行为。如果您曾经使用过某种脚本语言或配置引擎，而且它们有变量的概念（有时叫属性值或AVP），那么通道变量的概念和它们几乎是一样的。它们仅是一个简单的名字与值的配对，可以传递给通道，可以设置数据值。有一个用于设置通道变量的app叫set，在拨号方案中，我们可以用它设置自己的通道变量：

    这个例子与之前的几乎相同，只是在外呼之前，我们将通道变量foo的值设置为bar。这个变量会一直保留到呼叫结束，甚至可以在呼叫结束后的CDR中引用它。



    用小块构建的东西越多，可以重用的相同底层资源就越多，从而使整个系统的使用变得更简单。例如：codec接口，除了它自己世界中的音视频包编解码之外，对内核的其它内容一无所知。一旦写了某个特定的codec模块，任何可以携带相应媒体流的终端接口都可以直接使用它。这意味着，如果我们有一个文语转换（TTS）模块可以工作，那么我们就可以在所有的FreeSWITCH支持的终端上生成合成的语音。如果系统支持更多的codec，TTS也会变得更有用；反过来，如果我们添加一可以使用某个codec的功能，也会使对应的codec模块变得更有价值。如果我们写了一个新的app模块，现有的终端立刻就能运行和使用这个app。

    

    https://blog.csdn.net/yetyongjin/article/details/96838256