IVR Call center cti设计原则
来源:互联网 发布:手机改编歌词软件 编辑:程序博客网 时间:2024/04/19 20:07
一个呼叫中心的IVR系统,该用什么模式呢? ivr系统应该是一个状态机模型,里面充斥着各种线路控制的状态和事件(空闲,震铃,挂机,放音,录音,加入会议,离开会议,两通道连接。。。。。)不过总的来说,线路部分的状态和事件不会很多,并且是不会经常变化的,可以看成是固定的就那几个。 然后,做应用的时候,业务逻辑引入的自定义状态就不可预料了。如何进行解耦?如何保证底层线路控制部分的纯洁不被业务逻辑所破坏?IVR系统是一个实时性要求很高的系统,同时也是一个并发量很高的系统(绝对不能用一个通道一个线程的方法,只能用状态机轮询)。IVR系统的底层可以是各个厂家的语音卡,可以是各个厂家的交换机,可以是来自IP的呼叫,甚至是短信,邮件等各种资源。这些应该要和业务逻辑完全分离。 我设想的是用分布式的进程来解耦。外围的线路资源(如语音板卡)做成独立的一个进程,不参与业务逻辑,做成一个只会做事,而不知道为什么做的“傻瓜”。 业务逻辑单独也是一个进程,和数据库打交道的也单独做成一个进程。。。。这样,处理业务逻辑的程序就是一个依照业务逻辑发号命令,但是不知道如何具体实现这些命令的人(COMAND模式?),其他的各类资源网关都和这个业务程序打交道,各资源网关彼此之间不打交道(中介模式?)。 如此思路下,那么一个业务流程的执行就大概如下了: 业务程序执行流程,发现需要对用户放音,就发个包(SOCKET通信)给板卡程序,发现需要执行一个存储过程,就发个包给数据库程序,发现需要发条短信,就发个包给短信程序,发现需要做****,就发个包给&&&&. 这样,板卡程序就只管听命令,对指定的通道放音,录音,加入会议之类。然后把底层线路的变化事件发包给业务程序,数据库程序也是,只管按要求执行存储过程,然后把结果发包给业务程序,短信。。。。等等。这样,整个系统就很容易拓展了,并且外围的程序也很容易编写,用三汇卡,就作个三汇卡函数封装的板卡程序,用AVAYA交换机,就做个对应的交换机程序。要IP应用,就做个IP网关程序等等。 然后,问题就是,这个最核心的业务程序怎么设计啊?该用那些模式来实例化业务流程?如何维护每个实例的状态?等等,期待大家的讨论,谢谢
- IVR Call center cti设计原则
- ACD CTI IVR
- IVR服务器与CTI服务器
- CALL CENTER
- FreePBX中IVR设置的例子 - [CTI开发]
- CALL CENTER 2
- call center流程描述
- IVR
- Livedoor 中国大连 Call Center
- 呼叫中心(Call Center)
- call center 的未来 ippbx
- 企业级Call Center自建还是外包?
- Call Center核心词汇含义及功能
- call center 呼叫中心常用名词解析
- Call Center Stats for Asterisk 之二
- 易用为王--如何设计合理的IVR流程
- 设计原则 - 开闭原则
- 设计原则-开闭原则
- python满足你需要的50个模块
- WinCE 开始菜单StartMenu_Create()函数代码分析
- C# 中的常用正则表达式总结
- 使用RAPI库操作移动设备——C#语言描述
- WINCE注册表应用
- IVR Call center cti设计原则
- WinCE 桌面修改
- 用C#实现生成PDF文档
- 漫谈WinCE下的格式化
- Rational Rose 2003 逆向工程转换C++ / VC++ 6.0源代码成UML类图
- 记下我的程序人生
- 对立的虚体!
- C#网络编程(基本概念和操作) - Part.1
- c语言经典算法之数小孩