国航CTI方案建议书

-.z国航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〔monObjectRequestBrokerArchitecture，公共对象请求代理体系构造〕是一套由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效劳和应用。两种方案的比照：在双机主备方式下，一旦主CTI效劳器发生故障，则在效劳中断过程中，所有的座席都会受到影响在负载分担、冗余备份的方式下，正常情况下两台CTI效劳器各自负责一局部的座席通讯。在CTI链路上实现负载分担的功能。一旦任何一台CTI效劳器发生故障，则在效劳中断过程中，只有一局部的座席会受到影响推荐采用：负载分担、冗余备份的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/PB*内部有一个路由点VDN。所有的呼叫会首先到达这个路由点，由路由点做出目的地选择。一般情况下，当一个呼叫进入路由点后，路由点会通过CTI链路向后台的CTI效劳器发送路由请求，在这个路由请求中包括所有与这个呼叫有关的信息，如主叫号、被叫号、客户**、选择的效劳类型等，CTI效劳器收到这个路由请求后，根据预先定义的路由策略返回路由结果给ACD/PB*内的路由点，这个路由结果可以是大客户组组号或是相关业务组的组号。路由点收到路由回复后，将原先的呼叫转移到相关目的地址。在这个过程中，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、D、IIOP、MQAPI、*ML等，与第三方的电子商业系统或平台集成在一起。图.与第三方电子商务系统的集成除了与SiebelCRM可以实现无缝的集成，AIC还支持集成到许多优秀的其它CRM产品中去，如PeopleSoft、SAP、Ony*、Oracle等。图：AIC与SiebelCRM7.5的集成界面图：AIC与PeopleSoft8CRM的集成界面数据库配置：AIC需要有一台数据库效劳器来存储CTI所需要的相关数据，如各个效劳器的配置信息、座席配置信息、路由策略等等。AIC支持所有主流的数据库效劳器厂家，如MSSQL、Oracle或DB2等。这个AIC的数据库即可以单独设一台，也可以与后台的业务数据库或客户数据库放在一起。CTI数据库的冗余配置CTI所使用的数据库里面存储了所有与CTI效劳相关的数据，如各个效劳器的配置信息、座席的登录及配置信息、路由策略、客户交互历史信息等。一旦数据库出现问题〔数据库本身或连接故障〕，直接导致的最主要的后果就是：新的座席无法登录，因为座席登录的密码验证必须通过数据库来进展。原先已经登录的座席不受影响。客户的交互信息和呼叫过程信息在呼叫完毕后无法写回到数据库进展保存。新的业务流程和更新配置无法上载到数据库。因此，这个数据库的冗余性也需要重点考虑。我们建议对这个数据库采用数据库厂家或操作系统厂家所提供的效劳器群集效劳〔ClusterService〕。采用2台数据库效劳器，对外公开一个虚拟的IP地址。内部2台数据库效劳器通过专用的网络连接，保持数据的同步。利用磁盘存储阵列来保存所有的数据源。群集运行数据库效劳的单独一个实例，该实例由群集效劳进展管理。在任一个时间，均仅有一个节点在积极地对客户机请求作出响应。如果活泼节点发生故障，则群集中的另一备用〔被动〕节点可以运行同一个数据库效劳实例〔该实例由备用节点中的群集效劳初始〕并开场提供当初由发生故障的节点拥有的整套数据的效劳。在该配置中，两个效劳器共享一个主数据库和同一组用户数据库。除了由数据库厂家提供基于群集效劳的冗余性之外，AvayaCTI本身也提供了一些机制，在数据库发生故障的时候，尽最大的可能来保护数据的完整性。例如，上面提到的，当数据库发生故障无法操作的时候，客户交互信息及呼叫过程数据无法写回到数据库。AvayaCTI在这个时候提供了临时文件写回机制的保护措施。一旦发生数据库无法写回的时候，CTI会自动将所有的交互数据保存在一个临时的文本文件上，存放在效劳器上的*一个特定目录下。当数据库恢复操作后，可以再将这个文本文件上的内容回写到数据库中，尽最大的可能保证了历史数据的完整性。并且，整个这个过程是由系统自动完成的，无需任何的人工干预。CTI系统完全失效情况下的ACD接收对于Avaya的ACD/PB*系统来讲，CTI与语音交换是2个不同的局部，相互之间没有直接的依赖关系。即使在CTI系统完全失效的情况下，客服中心的呼叫处理和ACD分配也不受影响。下表列出的是在CTI系统完全失效情况下，ACD可以接收处理的功能：CTI完成的功能ACD的接收方式智能路由由ACD内部的缺省静态路由表完成软的控制座席通过仍然可以完成应答、呼出、转移等各项功能呼叫中心座席控制座席通过仍然可以实现登录、签出、工作状态改变等功能屏