IVR Call center cti设计原则

一个呼叫中心的IVR系统,该用什么模式呢? ivr系统应该是一个状态机模型,里面充斥着各种线路控制的状态和事件(空闲,震铃,挂机,放音,录音,加入会议,离开会议,两通道连接。。。。。)不过总的来说,线路部分的状态和事件不会很多,并且是不会经常变化的,可以看成是固定的就那几个。 然后,做应用的时候,业务逻辑引入的自定义状态就不可预料了。如何进行解耦?如何保证底层线路控制部分的纯洁不被业务逻辑所破坏?IVR系统是一个实时性要求很高的系统,同时也是一个并发量很高的系统(绝对不能用一个通道一个线程的方法,只能用状态机轮询)。IVR系统的底层可以是各个厂家的语音卡,可以是各个厂家的交换机,可以是来自IP的呼叫,甚至是短信,邮件等各种资源。这些应该要和业务逻辑完全分离。 我设想的是用分布式的进程来解耦。外围的线路资源(如语音板卡)做成独立的一个进程,不参与业务逻辑,做成一个只会做事,而不知道为什么做的“傻瓜”。 业务逻辑单独也是一个进程,和数据库打交道的也单独做成一个进程。。。。这样,处理业务逻辑的程序就是一个依照业务逻辑发号命令,但是不知道如何具体实现这些命令的人(COMAND模式?),其他的各类资源网关都和这个业务程序打交道,各资源网关彼此之间不打交道(中介模式?)。 如此思路下,那么一个业务流程的执行就大概如下了: 业务程序执行流程,发现需要对用户放音,就发个包(SOCKET通信)给板卡程序,发现需要执行一个存储过程,就发个包给数据库程序,发现需要发条短信,就发个包给短信程序,发现需要做****,就发个包给&&&&. 这样,板卡程序就只管听命令,对指定的通道放音,录音,加入会议之类。然后把底层线路的变化事件发包给业务程序,数据库程序也是,只管按要求执行存储过程,然后把结果发包给业务程序,短信。。。。等等。这样,整个系统就很容易拓展了,并且外围的程序也很容易编写,用三汇卡,就作个三汇卡函数封装的板卡程序,用AVAYA交换机,就做个对应的交换机程序。要IP应用,就做个IP网关程序等等。 然后,问题就是,这个最核心的业务程序怎么设计啊?该用那些模式来实例化业务流程?如何维护每个实例的状态?等等,期待大家的讨论,谢谢

你可能感兴趣的:(数据库,socket,存储)