研究IVR软件开发

3 api ivr telephony jtapi jain-sip

我工作的公司正在寻找与任何潜在的PBX/IVR或PBX组合高度兼容的IVR实施,或者提供我们自己的托管解决方案.

因此,我们的想法是创建一个与任何潜在平台接口的应用程序,并为IVR提供呼叫控制和语音对话/交互.

我到目前为止看过的技术(我们想使用Java)是Java Telephony API(JTAPI)JAIN-JCC(Java Call Control)API等.这些API的基本要点对我来说很有意义,但我不能把它放在一起的是我为呼叫控制和语音IVR/VXML创建的应用程序将如何以独立于平台的方式连接到电话系统.我是怎么接听电话系统的电话的?

这些API和库似乎没有回答这个问题,这让我相信独立于平台的解决方案是不可能的,而且它始终是特定于实现的.还有JAIN-SIP,如果我可以将所有呼叫转换为SIP,那么也许我可以通过这种方式创建通用呼叫控制/ IVR应用程序.

如果我在这里发出任何无知或误解,请原谅我,我对任何一种电信技术都是全新的 - 任何想要让我直截了当的人?我非常感激,在这一点上,细节实现层面上的联系非常模糊,有时候我需要一点手握.任何帮助或推动正确的方向都会有所帮助.

上周我一直在倾注规格和API.:)

编辑 - 我忘了提到我们更愿意在内部开发这个,如果可能的话,在成本/收益方面很聪明 - 如果可能的话,不是真的想在集成平台上花钱 - 这就是我的工作:)

Jim*_*ush 5

我在这个领域工作了很多年.ChrisW的答案非常好.以下是一些可能对类似情况的人有帮助的其他信息.

我假设您提供的是一个前提解决方案,因为如果您托管您的应用程序,大多数集成问题都会消失.如果您需要更改设施,并将电话逻辑与对话和业务逻辑隔离开来,那么翻译应该不会太困难.

IVR/PBX集成挑战以多种方式出现:

电话:

通过电话,我的意思是第一方呼叫控制.电话线的特点.

  • 呼叫到达信息(ANI/DNIS).假设您在更高级别工作,例如VoiceXML,您仍然可能遇到各种各样的问题.一些:
    • 数据存在.并非所有交换机都提供此数据.更糟糕的是,数据可能仅适用于某些交换机配置.该配置可能与您的应用程序或呼叫中心的其他需求(转移)冲突.
    • 数据格式.根据您的应用程序,这可能是也可能不是问题,但数据的格式可能会因交换机而异.
  • 不同的转移类型.根据周围电话网络的架构,您的传输类型可能需要改变.通常,VoiceXML中可用的默认hook-flash传输在转移到本地呼叫中心的代理或ACD时将起作用.但是,非现场/关闭PBX/PBX-PBX传输,需要作为监督(2步)传输执行.请注意,VoiceXML标准不包括此类传输.它仅涵盖盲转移和会议,但大多数平台提供了访问额外转移逻辑的机制.

计算机电话集成(CTI):

通过CTI,我的意思是通过与PBX的数据集成进行第一方或第三方呼叫控制.

  • 功能差异.超过大多数人可能想象的.如果您在有ACD的呼叫中心,这可能会非常复杂.ACD功能可能与供应商的供应商截然不同.
  • 事件流/数据格式.同样,它们可能非常不同.在某些开关上,您将获得丰富的事件.在某些环境中,您几乎看不到任何环境.
  • 通话跟踪.跟踪数据弹出交换机周围的呼叫并不总是像获取呼叫引用ID并将数据作为密钥粘贴在数据库中一样容易.在几个开关上,随着呼叫在系统周围移动,ref id会发生变化.您需要编写软件来跟踪转换并根据内部引用进行更新.哦,并非所有交换机都支持refid ......

总之,您不仅会看到交换机之间的差异,而且会切换不同的协议,由于服务/配置类别甚至每个设备的差异.在后面,我的意思是你可以根据代理桌面上的电话设置看到不同的行为(与CTI数据弹出相关).

没有单一的解决方案可以隐藏所有这些,并且鉴于一些通用解决方案不可能存在的差异.但是,可以创建特定用例的约束模型.它不是很容易,并且需要很多开关来创建规范化层的经验.

所以现在我已经概述了问题的更大区域(是的,还有其他的:-(),一些建议:

  • 将应用程序逻辑与电话逻辑分离.假设您需要多个插件模块来进行电话集成.
  • 避免在规范化层附近切换特定功能.如果您要在代理桌面上部署,则无法避免它们,因为呼叫中心希望您将利用或至少兑现其特定的ACD配置(如果您的呼叫未在其报告中正确显示,则您可能会失去客户)
  • 选择支持各种电话协议的主IVR供应商,并公开丰富的扩展传输功能集.
  • 虽然标准......很差......他们就是你所拥有的.在VoiceXML中编写您的应用程序.如果您在主要供应商无法支持的交换机或呼叫中心达成交易,则可以更换IVR供应商.
  • 有各种CTI协议.TAPI,JTAPI,TSAPI,CSTA等.没有一个答案.有几个商业规范化层可以为您提供更一致的API,但每个交换机的功能和事件流仍然不同.计划写入多个接口或支付第三方API.这里没有简单的答案,因为第三方产品的成本可能是一个昂贵的附加产品,但实现各种交换机的开发工作可能更多.
  • 与一组有限的交换机供应商或CTI服务器(例如Cisco ICM,Genesys T-Server)合作.它限制了您的市场,但最大限度地降低了集成成本.但是,这种伙伴关系可以帮助您利用销售并获得更多客户.