呼叫处理

XSwitch 在技术上是一个背靠背的用户代理，每路通话在 XSwitch 中称为通话的一条“腿”，为便于描述，我们做如下约定：

• a：话机，或一个分机号
• b：另一个话机，或分机叫
• c：第三个话机
• d：外线号码，如手机号
• e：另一个外线号码，如手机号
• x：XSwitch，本交换机
• t：Trunk，中继，第三方 SIP 服务器
• controller：控制平台，用于呼叫控制
• db：数据库
• ai：人工智能平台
• nlp：NLP 平台
• 所有的呼叫方向都是针对 XSwitch 而言，即 a -> x 称为呼入，x -> b 称为呼出。

常用的呼叫场景如下：

• 单腿呼叫：电话呼入后，播放欢迎音，用户通过 DTMF 按键、语音等跟系统交互。整个过程中只有这一路通话。
• 桥接的呼叫：电话呼入后，桥接到另外一路，一般会有两条腿。
• 会议呼叫：电话入呼后，进入一个会议，一般会有 1 ～ n（n ≥ 1）条腿。

这些场景又能组合出很多场景，下面我们分别来看。

XSwitch 上的电话呼入后，先查询路由（Route，Dialplan），如果找不到路由，则呼叫失败，返回空号。如果路由错误，可能回其它失败信息。

找到路由后，可以执行相应的动作，如应答，桥接等。

XSwitch 针对呼入的电话，会指定一个呼叫源。呼叫源用于标志电话“从哪里来”，它本身是一个没有意义的字符串，名称可以任意起，比如，每个分机号可以指定一个呼叫源，当该分机打电话时，我们就知道该通话是从哪里发起的，以后去路由里查找相应的路由，好知道电话“到哪里去”。这个到哪里去称为目的地，也就是决定怎么处理这路通话。

IVR 是交互式语音应答，如果目的地是 IVR，就会由 IVR 程序自动处理来话。比如自动应答这路呼叫，提示用户通过按键选择不同的菜单等。呼叫拓扑和流程如下：

不管是内部还是外部来话，都可以转分机，呼叫拓扑和流程如下：

分机打分机可以直接查找路由，路由目的地是本地分机。

分机打外线与分机打分机流程类似，区别是路由的目的是通常是网关或 IP 地址。

外线打分机流程与分机打分机类似。

下面是几种来话处理方式。

上述的几种方式都是直接在路由里处理的。

a 呼入，x 查找路由，执行系统路由：ai {url=http://controller-ip:port}，向 Controller 通过 HTTP 发送来话信息，HTTP 返回相关指令。

处理流程与 AI API 类似，将电话路由到系统路由：xcc cn.xswitch.ctrl.controller-name。

当有多个电话呼入时，c 一般有以下两种策略：

• 对第二路呼叫回被叫忙（Busy，b 听忙音）
• 将第一路呼叫 Hold（保持，这时 b 听回铃音），接听第二路呼叫，b 与 c 通话。

还是 a 与 b 同时呼 c 的场景。

• 可以在 x 上设置并发限制，对第二路通道在 x 上直接给 b 回忙音。
• 可以执行排队，x 应答，播放提示音，告知 c 忙，然后放等待音乐，a-x-c 挂机后，x 再呼 c，接通 b-x-c。

XSwitch 上排队有两种方式 FIFO 和 Callcenter。

• a、b 两个座席签入队列 888
• d、e 呼叫 888 客服号进入 x，将两个呼入放到队列 888
• d、e 听等待音乐
• FIFO 或 Callcenter 查找空闲坐席，发现 a 和 b
• 对 a 和 b 分别振铃
• 如果有新电话呼叫，在 d、e 挂机前只能进入队列听音乐
• XSwitch 中的 FIFO 和 Callcenter 自动跟踪 a 和 b 的忙闲，根据事先配置的策略进行电话分配

电话呼入后，通过 AI API 或 XCC API 通知并询问 controller 下一步怎么办，controller 会跟踪座席状态，告诉 x 将电话转接到哪个座席。

在这种状态下，controller 可以通过订阅相关座席分机的通话事件，感知话机的通话状态，以便对电话进行分配。