工控软件开发:IVR软件开发探讨(ivr platform)

我工作的公司正在寻找与任何潜在的 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。:)

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

5

我在这个空间工作了很多年,ChrisW 的回答非常好,这里有一些附加信息,可能对处于类似情况的人有所帮助。

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

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

Telephony:

通过电话,我的意思是第一方呼叫控制。电话线的功能。

呼叫到达信息 (ANI / DNIS)。假设您在更高级别的工作,如 VoiceXML,您仍然可以有各种各样的问题。只是一些:

数据存在。并非所有交换机都提供此数据。更糟糕的是,数据可能仅在某些交换机配置下可用。该配置可能与应用程序或呼叫中心的其他需求(传输)冲突。

数据格式。根据您的应用程序,这可能是问题,也可能不是问题,但是数据的格式可能会因交换机而异。

不同的传输类型。根据周围电话网络的体系结构,您的传输类型可能需要有所不同

计算机电话集成 (CTI):

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

功能差异。比大多数人想象的要多。如果您在具有 ACD 的呼叫中心,则可能会非常复杂。ACD 功能可能与供应商之间存在很大差异。

事件流 / 数据格式。同样,它们可能非常不同。在某些交换机上,您将获得丰富的事件集。在某些环境中,您几乎看不到。

呼叫跟踪。跟踪交换机周围的呼叫以进行数据弹出并不总是像获取呼叫引用 ID 并将其用作密钥将数据粘贴到数据库中那样容易。在多个交换机上,ref id 会随着呼叫在系统中的移动而更改。您需要编写软件来跟踪转换并根据内部 ref id 对其进行更新。哦,并非所有交换机都支持 ref id...

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

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

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

将应用程序逻辑与电话逻辑分离。假设您需要多个插件模块来进行电话集成。

避免在标准化层附近部署特定于交换机的功能。如果您在台式机上部署这些功能,则无法避免它们,因为呼叫中心希望您利用或至少遵守其特定的 ACD 配置(如果您的呼叫未正确显示在其报告中,则有失去客户的风险)

选择一个主要的 IVR 供应商,该供应商支持广泛的电话协议,并提供丰富的扩展传输功能集。

虽然标准...很差...它们是您所拥有的。用 VoiceXML 编写您的应用程序。如果您在交换机或呼叫中心达成了主要供应商无法支持的协议,则可以更换 IVR 供应商。

有各种各样的 CTI 协议。TAPI,JTAPI,TSAPI,CSTA 等等。没有一个单一的答案。有几个商业规范化层给你一个更一致的 API,但是每个交换机的功能和事件流仍然不同。要么计划写入多个接口,要么为第三方 API 付费。这里没有简单的答案,因为第三方产品的成本可能是一个昂贵的附加组件,但是实现一个

与有限的一组交换机供应商或 CTI 服务器 (例如 Cisco ICM 、 Genesys T-Server) 合作。它限制了您的市场,但最大限度地降低了集成成本。但是,这种伙伴关系可以帮助您利用销售并获得更多客户的访问权限。

4

几年前我为VoiceGenie工作:他们做了 (我在这里使用过去时态只是因为我不知道他们现在在做什么,而不是因为他们不再这样做) 一个 VoiceXML 引擎,其中:

是一个 Linux 盒子

已连接第三方语音转文本和文本转语音引擎(通过与特定于引擎的 API 连接)

解释 VoiceXML(使用其自己的 VoiceXML 解析器),并通过驱动第三方语音到文本和文本到语音引擎来执行它

他们雇我来连接他们的盒子来调用控制系统:我做的第一个系统是思科的(相反,我看到 VoiceGenie 现在归 Genesys 所有)。他们的引擎还支持非 VoiceXML 应用程序,例如它暴露了 Java 应用程序接口。

总之:

各种电话系统具有专有的呼叫控制 API;和 / 或它们可以支持标准的呼叫控制协议 (例如 SIP) 和 / 或 API (例如 JTAPI 、 TAPI 、 CCXML),并且如果它们支持的话,则或多或少地做到这一点。

您可能会发现第三方引擎(例如Genesys Voice PlatformMicrosoft Office Communications Server等),它们为您提供了一些统一的 API,并处理和支持(或不支持)与其他组件的互操作。

我不是这个领域的产品经理,系统工程师,网络架构师,领域专家。

但是它们通常都支持一些协议和 API

一些仅支持专有,广告 / 或一些支持一个或多个标准。

因此,我们的想法是接口到最支持的 API 或协议。

我会质疑这个商业案例,但我认为你应该找到一个电话工程师,他有特定的领域专业知识和产品 / 实现知识。我作为一名软件开发人员遇到了我上面发布的内容,但我没有领域专业知识。

那是 SIP 吗?

SIP 是一个协议,而不是一个 API。这东西是在层,例如作为一个应用程序,你可能会使用:

较低级别:具有自己的 API 的 SIP 协议栈;您使用此 API,了解 SIP 对话框的外观,并(仅)与了解 SIP 的系统交谈

更高级:VoiceXML / CCXML 引擎 (或 TAPI 或 JTAPI 引擎);您写 XML (或使用 TAPI 和 JTAPI API);并且引擎 (根据哪个引擎它是) 可能有它使用对话与使用 SIP 的组件的一个内置 SIP 堆栈,和 / 或它可能有使用其他 (非 SIP) 协议的组件的其他协议堆栈。

思科只有一个(专有)协议,我可以使用,与他们的“智能联系管理”(即呼叫中心)系统交谈。我认为 Genesys 有一个封闭的专有 API / 协议。

如果是这样,那么我的呼叫控制和 IVR 解决方案最好实现为 JTAPI 应用程序或某些变体的 SIP 前端?

我很困惑你想做什么,在堆栈中你想成为(不是我可以说任何有用的东西,如果我知道)。

我认为也许你应该与供应商交谈:找出他们可以为你做什么(除非你试图与他们完成,这将是困难的)。

你能缩小“任何潜在的 PBX / IVR 或 PBX 组合”的含义吗?

0

另外,作为对我的问题的替代答案,我们偶然发现了一个开源项目,该项目使用 JTAPI 创建了一个接口,以提供对多个电话系统(板,PBX 和 IP电话)和平台的支持。这样,我就可以像我提到的那样开发一个应用程序,并且无论系统如何,它都适用于许多不同的系统。

它被称为“通用 JTAPI”:

://gjtapi.sourceforge.net/
0

使用Twilio为自己节省一些痛苦和开发时间。基本上他们处理 PSTN / VOIP 连接,您只需告诉他们如何处理 XML / HTTP REST。他们有helper libraries in a variety of languages,包括 Java

本站系公益性非盈利分享网址,本文来自用户投稿,不代表边看边学立场,如若转载,请注明出处

(59)
Ran e:获取此线程运行了多少秒(e7 ran)
上一篇
安卓源代码:三星安卓时钟应用程序-源代码
下一篇

相关推荐

发表评论

登录 后才能评论

评论列表(32条)