国航CTI方案建议书.docx

国航CTI方案建议书.docx

《国航CTI方案建议书.docx》由会员分享，可在线阅读，更多相关《国航CTI方案建议书.docx（18页珍藏版）》请在冰豆网上搜索。

国航CTI方案建议书

国航CTI方案建议：

CTI整体构架方案一：

双机主备

双机主备方案主要是指在网络环境中部署两台CTI服务器，一主一备。

在正常情况下，所有的CTI功能，如路由、呼叫控制、数据传递等都是由主CTI服务器完成，备份CTI服务器运行但不负责实际的控制。

当主CTI服务器发生故障无法正常工作时，备份CTI服务器会自动接管所有的CTI功能。

如上图所示，AICTS-1是主CTI服务器，在备份中心的AICTS-2是备份CTI服务器。

两个CTI服务器通过2个不同的CTILink连接到交换机上。

在正常情况下，所有的座席应用以及路由应用都使用总中心的TS-1服务器，TS-2在同一时间仍然处于运行状态，但不负责控制。

当总中心的TS-1服务器发生故障无法正常工作时，所有的座席软电话应用以及路由程序都会出现短暂的无法正常工作的状态。

通过AIC的CORBA总线的故障自动检测及冗余接管机制，CORBA总线服务程序会自动将所有座席端的CTI请求转送到TS-2备份CTI服务器上，同时交换机内部的路由请求也会将路由信息送到TS-2上获取路由决策信息。

因此，在短暂的接管过程后，所有的CTI应用（软电话控制、路由、数据传递等）都将自动使用TS-2服务器，因此TS-2也就成为了主CTI服务器。

客户端与CTI服务器端的冗余处理

在座席PC与CTI服务器之间的系统冗余主要是依靠CORBA的软件总线来实现的。

CORBA（CommonObjectRequestBrokerArchitecture，公共对象请求代理体系结构）是一套由OMG（对象管理组织）提出的应用软件体系机构和对象技术规范，其核心是一套标准的语言、接口和协议，以支持异构分布式应用程序间的互操作性及独立于平台和编程语言的对象重用。

CORBA体系得到了业界众多享有声誉的软硬件厂商的支持，如IBM、Lucent、Unisys、Sun、HP、Philips、Borland、Iona、BEA等。

CORBA体系的最大特点在于：

▪跨平台的支持能力和互操作性，支持各种不同的软、硬件平台和系统

▪分布式处理的能力。

由于CORBA系统引入了中间件的概念，即事务代理，由中间件完成客户机与服务器之间的通信，使得服务器对于客户机的位置相对透明，取消了原有分布式计算模型中客户机、服务器之间的一一对应关系。

CORBA客户机可以在运行时动态获得服务对象的位置，并且可以对对多个服务对象提交事务请求，因此，极大地推动了分布计算的发展。

▪软件总线。

在任何环境下、采用任何语言开发的软件只要符合接口规范的定义，均能够集成到分布式系统中。

Avaya的CTI产品AIC是完全构架在CORBA体系机构上的，所有的服务器对象和客户端对象都是作为CORBA总线上的一个接入部分。

如下图所示：

客户端只需要负责向CORBA总线发送CTI的命令请求，CORBA总线负责将该客户端的CTI请求发送给相应的服务进程，如TSServer。

如果某个TSServer无法正常处理该CTI请求，CORBA总线会根据预先设定的失败接管机制，依次顺序寻找可用的下一个TS服务进程。

对于客户端来讲，整个过程是完全透明的。

例如，某个座席向TS发送电话应答的命令请求。

正常情况下，这个命令请求会通过CORBA总线传递给TS服务器1来处理。

但是，如果一旦TS服务器1出现故障，无法执行这条命令的话，CORBA总线会根据预先设定的失败接管顺序，将该条指令发送给下一个可用的TS服务器，如TS服务器2。

假设TS服务器2同样也产生了故障，无法正常工作，那么CORBA总线会继续寻找下一个可用的TS，直到所有的TS服务器都无法完成这项指令，才返回错误信息给客户端。

CTI整体构架方案二：

双机负载分担、冗余备份

在第二种方案中，不存在一主一备的CTI服务器。

在网络中同时有两台CTI服务器并行工作，各自负担一部分的CTI服务请求和任务。

两个CTI服务器相互之间实现失败接管机制，即当其中一台CTI服务器发展故障时，另外一台CTI服务器可以自动接管原先它所控制的所有设备和应用。

如上图所示，TS-1和TS-2同时工作。

TS-1负责总中心北京的所有CTI应用（绿线所示），TS-2在成都备份中心负责成都和上海以及其他分公司的所有CTI应用（棕色线路所示）。

各自负责一部分的应用，实现在CTI层面的负载分担功能。

假设如果总中心的TS-1服务器发生故障后，影响到了总中心本地的CTI应用。

通过AICCORBA总线的调度和故障接管机制，在成都的TS-2服务器将自动接管北京总中心的CTI服务和应用。

两种方案的对比：

1、在双机主备方式下，一旦主CTI服务器发生故障，那么在服务中断过程中，所有的座席都会受到影响

2、在负载分担、冗余备份的方式下，正常情况下两台CTI服务器各自负责一部分的座席通讯。

在CTI链路上实现负载分担的功能。

一旦任何一台CTI服务器发生故障，那么在服务中断过程中，只有一部分的座席会受到影响

3、推荐采用：

负载分担、冗余备份的CTI部署方式

单点CTI的部署方式：

AIC的TS服务器时通过AvayaAES（ApplicationEnablementServices）服务器与交换机进行通讯的。

AES服务器与AvayaCM交换机上的CLAN板卡，建立两条CTI的链路（可以是与一块CLAN建立2条逻辑的CTI链路，也可以与两块CLAN板建立2条独立的物理上的CTI链路）。

CTI的消息量可以自动在这2条CTI链路上实现冗余和负载分担。

AIC上的TS服务器则通过AES服务器上的CVLAN软件进行通讯，实现CTI的功能。

AES服务器的备份

由于AES服务器是连接交换机与CTI服务器的关键部件，因此AES服务器的可靠性和冗余性也相当重要。

如上图所示，针对国航的项目，我们建议采用如下方式：

采用2台AES服务器AES-1和AES-2，分别通过两个CLAN的链路与交换机连接

中心点北京的AIC服务器分别建立TS-1与AES-1、TS-2与AES-2的两条链路

备份中心成都的AIC服务器分别建立TS-2与AES-2、TS-3与AES-1的两条链路

这样的话，任何一台AES服务器发生故障，都不会影响到北京中心和成都中心的两台AIC服务器的正常工作。

AIC基于CORBA体系的失败接管机制（Failover）是建立在域（Domain）概念上的。

在AIC中，它把所有的服务进程和座席都以域来归组，所有的任务或请求都会首先使用自己域内的资源和服务，只有在自己域内的资源或服务处于不可用的状态时，它才会向其它域内的资源请求服务。

因此，AIC中的Failover是基于域与域之间的Failover。

在本次国航项目中，我们建议的域（Domain）的分组方式如下图所示：

将北京总中心的TS-1和座席分成一个域（蓝色的Domain），将成都、上海以及其他分公司的TS-2和座席分成另一个域（黄色的Domain）。

通过配置，将这两个域建立起失败接管机制，即蓝色的Domain与黄色的Domain实现互为失败接管（Failover）。

根据本项目的要求，需要集中式的IVR系统（180路）。

考虑到冗余，我们建议将180路的IVR分到2台服务器上（2台SUNV240的系统，每一台90路IVR端口）

呼叫路由方式

交换机的内部路由功能：

基于CTI的路由功能：

呼叫进入交换机后，交换机会向CTI服务器发起路由请求。

在发出路由请求的同时，交换机会通过CTILink将相关的呼叫数据送给CTI服务器，如主叫号码、被叫号码、按键信息等。

CTI服务器会根据预先定义的路由规则，通过与数据库的信息交换，决定将此呼叫转接到某个特定的座席技能组，并将路由目的地（座席技能组号）号码传回给交换机，交换机通过交换，把这个呼叫转移到该技能组，然后通过技能组内部的座席分配策略（MIA或LOA）最终将呼叫接续到人工座席。

路由请求的冗余

在ACD/PBX内部有一个路由点VDN。

所有的呼叫会首先到达这个路由点，由路由点做出目的地选择。

一般情况下，当一个呼叫进入路由点后，路由点会通过CTI链路向后台的CTI服务器发送路由请求，在这个路由请求中包括所有与这个呼叫有关的信息，如主叫号、被叫号、客户帐号、选择的服务类型等，CTI服务器收到这个路由请求后，根据预先定义的路由策略返回路由结果给ACD/PBX内的路由点，这个路由结果可以是大客户组组号或是相关业务组的组号。

路由点收到路由回复后，将原先的呼叫转移到相关目的地址。

在这个过程中，VDN可以通过多条CTI链路，向多个CTI服务器发送路由请求，并且为每一个路由请求设定等待超时。

例如，VDN缺省将路由请求通过CTI链路1发送给CTI服务器1，并设定路由结果的返回时间为2秒钟；如果2秒钟之内，还没有收到路由结果的返回，VDN就会再次将路由请求通过CTI链路2发送给CTI服务器2。

同样，针对CTI服务2也可以设定超时，如2秒钟。

如果，所有的外部CTI服务器因为某些原因都没有返回路由结果的话，VDN可以利用ACD内部预先设定的缺省静态路由来完成呼叫的分配和转移。

基于IVR的路由功能：

呼叫进入交换机后，并不是由交换机向CTI发起路由请求，而是将此呼叫接续到IVR系统，IVR系统通过与CTI的连接接口，由IVR向CTI发起路由请求（同时将相关的呼叫信息传递给CTI），CTI仍然通过预先定义的路由规则和策略与数据库交换信息，决定路由的目的地。

路由目的地（座席技能组号）通过CTI返回给IVR后，IVR负责将此呼叫进行转接。

一般如果是简单的语音引导，可以直接在本地的语音网关里面，通过交换机的Vector和Announcement实现。

如果需要进行诸如卡号和密码的验证，或者需要通过TTS语音技术实现航班信息、天气预报等信息的播报，则可以将呼叫转接到中心点的IVR系统上来实现。

如果完成了IVR的功能，需要转接人工座席的话，IVR系统可以与交换机系统配合，根据需要将来话转接到北京、上海或者成都的座席上。

如下图所示：

CRM集成：

AvayaIC可以通过多种标准的协议接口，如CORBA、HTTP、DCOM、IIOP、MQAPI、XML等，与第三方的电子商业系统或平台集成在一起。

图.与第三方电子商务系统的集成

除了与SiebelCRM可以实现无缝的集成，AIC还支持集成到许多优秀的其它CRM产品中去，如PeopleSoft、SAP、Onyx、Oracle等。

图：

AIC与SiebelCRM7.5的集成界面

图：

AIC与PeopleSoft8CRM的集成界面

数据库配置：

AIC需要有一台数据库服务器来存储CTI所需要的相关数据，如各个服务器的配置信息、座席配置信息、路由策略等等。

AIC支持所有主流的数据库服务器厂家，如MSSQL、Oracle或DB2等。

这个AIC的数据库即可以单独设一台，也可以与后台的业务数据库或客户数据库放在一起。

CTI数据库的冗余配置

CTI所使用的数据库里面存储了所有与CTI服务相关的数据，如各个服务器的配置信息、座席的登录及配置信息、路由策略、客户交互历史信息等。

一旦数据库出现问题（数据库本身或连接故障），直接导致的最主要的后果就是：

▪新的座席无法登录，因为座席登录的密码验证必须通过数据库来进行。

原先已经登录的座席不受影响。

▪客户的交互信息和呼叫过程信息在呼叫结束后无法写回到数据库进行保存。

▪新的业务流程和更新配置无法上载到数据库。

因此，这个数据库的冗余性也需要重点考虑。

我们建议对这个数据库采用数据库厂家或操作系统厂家所提供的服务器群集服务（ClusterService）。

采用2台数据库服务器，对外公开一个虚拟的IP地址。

内部2台数据库服务器通过专用