常规基于电话的呼叫中心有几大部件：接入、IVR、ACD、座席、录音和业务控制软件等。
近年又增加了AI机器人，本质上AI机器人和座席功能类似，但是，可能控制信令会较为不一样。
IVR可能利用iSX4000交换机的能力，但是需要和业务控制软件交互，基本上是中间过程，很难做到冗余，因此，本文不考虑IVR的冗余。
ACD和业务控制软件是客户系统，不在毅航HA方案控制范围内，暂时也不考虑。
因此，本方案主要讨论接入、座席和录音的HA方案。也就是由HA方案保证设备故障、环境故障等原因导致设备切换后，外线和座席通话不间断，录音不丢失。
本文给出两种使用毅航HA能力的方案：冗余SBC方案和SDK接口方案。
冗余SBC方案利用毅航SBC冗余能力，在SBC切换后，会重建通话，保证外线和座席通话不间断。
SDK接口方案较为复杂，需要业务程序使用毅航SDK API在硬件切换后重建通话。
不管那种方式，都建议采用IP/中继并线方案来生成录音，保证设备切换不会影响录音功能。如果需要录音冗余，建议在SBC也产生一份录音。
两种方案都建立在iSX4000 HA控制模块的基础上。
HA控制器完成主备仲裁、切换、浮动IP地址管理、网口状态、网络状态以及基于redis的储存管理。基本结构如下图：
毅航SBC已经实现了冗余功能，两套相同配置的SBC通过配置后，可用配置成热备模式，保证系统的高可靠性：切换不导致通话间断。
冗余SBC的简单示意图如下：
网关软件和SIP主机软件都会将呼叫信息保存到redis server或者从redis server恢复，从而保证了通话不间断。
SBC就可用通过浮动IP地址，用SIP信令访问。
SBC和外部系统通过SIP信令对接，这样IVR/业务系统/座席相互间解耦，把语音交换和承载放到SBC完成，这样保证了即使是后端系统、设备故障和网络等环境问题导致设备切换，也能够保持建立的通话。
结构如下图：
一般SBC和业务系统通过SIP信令对接，在呼叫接通后，业务系统通过SIP REFER信令，将内线转呼到IVR/座席/AI机器人。
实质上就是通过呼转或者三方通话能力将话务在IVR/座席间切换，切换完成后，在信令层面是一个稳态，HA切换后，就可用恢复通话，保证了系统的高可靠性。
在这种模式下，业务系统重启并不影响已经建立的通话。
SDK接口方案较为复杂，需要客户的app来管理切换和恢复过程。
在传统的编程交换机模式下，每个模块都有它自己的IP地址（SIP/VoIP板），很难做到这么多的IP都在都浮动，因此，需要在这个模式下，参考毅航SBC的实现，采用linux服务器的NAT功能屏蔽交换机的IP地址，对外暴露服务器的IP地址，这个IP地址作为浮动IP地址。
整体结构和SBC类似，见下图：
注意：
客户app可用不使用内置的redis存储，采用自己的状态记录和恢复方案；
如果VoIP并发量较大，对语音断续间隔有要求，建议启用m3gc的冗余功能（图中未画出）。
由于客户app要执行HA切换的协调工作，下面简单列出主要的交互流程。
可能涉及到HA控制器、SIP模块、m3gc模块。流程是初始化、从master切换到backup和从backup切换到master。
注意：客户app调用SDK API，消息还是会通过mc转发，这里为了简单，隐去mc模块。
客户app除了原有执行打开各种资源（比如：gc通道、DSP通道、VoIP通道等）功能外，还需要通知HA控制器active。
流程如下图：
此为短暂的状态，HA控制器会根据配置执行主从决定，并根据情况返回状态事件。
整个节点从备用状态切换到主要状态。客户app在收到此事件后，要通知sip/m3gc执行deactive到active的转换，并开始执行自己的会话恢复操作。
如下图：
整个节点从主用状态切换到备用状态。客户app在收到此事件后，要通知sip/m3gc执行active到deactive的转换，并开始执行自己的清理操作。
并线录音是毅航产品中的标准产品，本文档暂时不做更多的讨论。
返回
