综述

XSwitch 是一个电信级的 IP 电话软交换系统和综合实时音视频多媒体通信平台

本文档描述 XSwitch XCC API 的设计原则和使用方法。XCC 是 XSwitch Call Control（XSwitch 呼叫控制）的缩写。

XSwitch 支持电话、传真、视频会议、呼叫中心等。支持主流的通信协议如 SIP、H323、WebRTC、RTMP 等，支持单机部署、云原生集群部署，支持无限扩容及动态伸缩。目标是为用户提供一站式语音、视频、会议解决方案，可以作为 IP-PBX、视频会议服务器、传真服务器、多协议网关、呼叫中心服务器等使用。XSwitch 提供 REST、Websocket 二次开发接口。XSwitch 基于开源技术构建，如 FreeSWITCH、PostgreSQL、Nginx 等。

XSwitch 是模块化，积木式按需叠加和无限伸缩扩容的通信产品，更可以通过定制支持集群部署，实现更强大的功能。

XSwitch 的位置、组件和逻辑关系如下图所示：

其中，SIP 话机通过 SIP 协议接入 XSwitch，管理员可以通过 Web 浏览器进行系统管理和维护，也可以通过 WebRTC 打电话，静态 Web 页面都由 Web 服务器提供，动态 API 请求会由 Web 服务器转发到 XSwitch 端进行处理。

XCC 相关的呼叫控制架构如下图所示：

其中，XSwitch 是核心交换节点，负责 SIP 信令和媒体交换。当 SIP 客户端（或通过运营商 IMS 线路）有呼入时，XSwitch 会通过消息队列通知控制器，控制器进而可以接管整个通话流程。控制器只是发送控制指令和消息，实际的音视频媒体都在 XSwitch 内处理。

有时候，为了定义更明确，XSwitch 又称为 XNode，即交换节点。消息队列使用 NATS 实现，控制器简称 XCtrl，因而也可以以下图方式表示，它其实与上图是等价的。

XSwitch 底层基于开源的 FreeSWITCH 开发，FreeSWITCH 作为 XSwitch 的核心交换节点，即 XNode。FreeSWITCH 性能强悍，但应对大规模应用时还是需要组建集群。因此我们设计了一个集群架构。

集群可以运行在裸金属服务器或虚拟机上，但更理想的环境是运行在 K8S 上，便于更方便地进行动态伸缩。FreeSWITCH 节点可以随时加入和退出服务，即所谓的动态伸缩。

系统中，所有组件都可以多个实例工作，多个组件可以分布在多个物理节点上，一个物理节点发生故障不影响整个集群运行。

通过消息队将通话和控制解耦。

FreeSWITCH 博大精深，用好 FreeSWITCH 需要对它充分了解，不仅仅是底层的 SIP 通信机制会让一些非通信专业的程序员头痛，FreeSWITCH 的通话控制逻辑也让很多人感觉晕头转向。考虑以下问题：

FreeSWITCH 是一个 B2BUA，当 A 发起一个呼叫时，FreeSWITCH 会创建一个 Channel，然后在内部会执行一个 Application 跟对端进行交互，比如playback就是直接播放一个声音，这个比较容易理解。当 A 想跟 B 通话时，FreeSWITCH 又会发起一个呼叫，然后将两路呼叫桥接起来（称为bridge）。更多方的呼叫可以用会议（conference）方式实现。

那么，FreeSWITCH 怎么知道在什么情况下执行哪些 Application 呢？很简单，你要告诉它。这就需要你预先制定一定的规则（我们称为dialplan，即拨号计划），FreeSWITCH 默认使用 XML 的拨号计划。

规则是死的，如果你希望更灵活的规则，你就可以用 Lua 脚本，或者 ESL 接口在外部进行控制。

问题是，通话逻辑是很复杂的，在通话中你不仅希望灵活地放音，还希望有转接、录音、收 DTMF、ASR 语音识别、甚至发送特定的 SIP 消息等，这些都需要很灵活的控制，但不幸的是，这很复杂。

我们再来思考一个更一般的 A 与 B 互通的逻辑：A 呼 B，如果有一方挂机，对方就会自动挂掉，这在电话交换专业中叫做“互不控制”。但是，实际的场景却又有不同的需求，比如在呼叫中心场景中，如果座席挂机，那么要引导客户对座席的服务进行评价，就需要客户侧不能自动挂机……

是的，FreeSWITCH 提供了很多实现方法，比如通过 Application 与拨号计划的有机组合，但什么时候需要转拨号计划？什么时候 Application 就可以？有什么副作用？要达到完全理解和领会并用得出神入化，需要很长时间。

本文档描述的接口就是致力于解决这些问题——让控制 FreeSWITCH 程序员不用纠结于 FreeSWITCH 的内部逻辑，从更高的视角分析业务需求，进而调用合适的 API 进行控制。

我们深知，看到本文档的程序员都是深资的程序员，大家熟悉各种数据结构和交互逻辑，只是不熟悉 FreeSWITCH 的交互和各种 SIP 控制。把专业的事情交给专业的人做，我们做好底层通信能力，您就可以省出时间更多的关注自己的业务逻辑。

通过消息队列将控制和媒体分离，最大程度地减少耦合，是我们设计的初衷。

值得一得的是，单独的这些 XCC 接口并不能完全让你无视 FreeSWITCH，但至少可以让你大部分无视。我们在 XCC 接口的基础上又做了一个更高级的呼叫中心服务和业务逻辑，就可以真正做到“与 FreeSWITCH 无关”了。

• XSwitch：XSwitch 软交换平台。
• XNode：XSwitch 交换节点，负责 SIP 信令和媒体交换，可以有多个。有时也简称 Node。
• XCtrl：XController，即 XSwitch 控制器。用于控制呼叫流程，用户自己实现，可以用任何语言编写。有时也简称 Ctrl。
• XCC：XSwitch Call Control，即 XSwitch 呼叫控制。
• NATS：一个消息队列。
• Proxy：代理服务器。SIP Proxy 用于 SIP 用户注册，通话负载分担等。HTTP Proxy 用于 HTTP 以及 Websocket 负载分担。
• IMS：IP Multimedia Subsystem，即 IP 多媒体子系统，运营商的系统。