探讨 IVR 软件开发 [关闭]
https://stackoverflow.com/questions/1457479
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
我工作的公司正在寻找一种与任何潜在的 PBX/IVR 或 PBX 组合高度兼容的 IVR 实施方案，或者提供我们自己的托管解决方案。
因此，我们的想法是创建一个与任何潜在平台交互的应用程序，并为 IVR 提供呼叫控制和语音对话/交互。
到目前为止，我研究过的技术（我们希望使用 Java）包括 Java 电话 API (JTAPI)、JAIN-JCC（Java 呼叫控制）API 等。这些 API 的基本要点对我来说很有意义，但我无法将我为呼叫控制和语音 IVR / VXML 创建的应用程序如何以独立于平台的方式连接到电话系统。我到底如何从电话系统接听电话？
这些 API 和库似乎没有回答这个问题，这让我相信独立于平台的解决方案是不可能的，并且它总是特定于实现的。还有 JAIN-SIP，如果我可以将所有呼叫转换为 SIP，那么也许我可以通过这种方式创建通用呼叫控制/IVR 应用程序。
如果我在这里有任何无知或误解，请原谅我，我对任何类型的电信技术都是全新的 - 有人愿意纠正我吗？我将非常非常感激，在这一点上，详细实现级别上的联系非常非常模糊，有时我需要一点帮助。任何帮助或推动正确的方向都会有帮助。
上周我一直在研究规格和 API。:)
编辑 - 我忘记提及，如果可能的话，我们更愿意在内部开发它，并且在成本/收益方面明智 - 如果可能的话，我们并不真正希望在集成平台上花钱 - 这就是我的工作:)
解决方案
我工作过 语音精灵 几年前：他们制作了一个 VoiceXML 引擎（我在这里使用过去时只是因为我不知道他们现在在做什么，而不是因为他们不再这样做），其中：
- 是一个Linux盒子
- 连接了第 3 方语音转文本和文本转语音引擎（通过与引擎特定的 API 接口）
- 解释 VoiceXML（使用自己的 VoiceXML 解析器），并通过驱动第 3 方语音转文本和文本转语音引擎来执行它
他们雇用我将他们的盒子连接到呼叫控制系统：我这样做的第一个系统是 Cisco 的（相反，我看到 VoiceGenie 现在属于 Genesys）。他们的引擎还支持非 VoiceXML 应用程序，例如它暴露了一个Java应用程序接口。
综上所述：
- 各种电话系统都有专有的呼叫控制 API；和/或它们可以支持标准呼叫控制协议（例如SIP）和/或 API（例如JTAPI、TAPI、CCXML），如果他们这样做了，或多或少都做得很好。
- 您可能会找到第 3 方引擎（例如这 Genesys 语音平台, ， 这 微软Office通信服务器, 等），它们为您提供一些统一的 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 组合”的含义？
其他提示
我在这个领域工作了很多年。ChrisW的回答非常好。以下是一些可能对处于类似情况的人有所帮助的附加信息。
我假设您提供了一个前提解决方案，因为如果您托管应用程序，您的大多数集成问题都会消失。如果您需要更改设施，并且将电话逻辑与对话和业务逻辑隔离，那么转换应该不会太困难。
IVR/PBX 集成挑战以多种方式表现出来：
电话：
我所说的电话是指第一方呼叫控制。电话线的特点。
- 呼叫到达信息 (ANI/DNIS)。假设您在更高级别上工作，例如 VoiceXML，您仍然可能会遇到各种问题。一些：
- 数据存在。并非所有交换机都提供此数据。更糟糕的是，数据可能仅在某些交换机配置下可用。该配置可能与您的应用程序或呼叫中心的其他需求（传输）冲突。
- 数据格式。根据您的应用程序，这可能是也可能不是问题，但数据的格式可能因交换机而异。
- 不同的传输类型。根据周围电话网络的体系结构，您的传输类型可能需要有所不同。通常，当转接到本地呼叫中心的座席或 ACD 时，VoiceXML 中可用的默认挂机转接将起作用。然而，异地/异地 PBX/PBX-PBX 传输需要作为受监督（2 步）传输来执行。请注意，VoiceXML 标准不涵盖这种类型的传输。它仅涵盖盲转和会议，但大多数平台都提供了访问额外转接逻辑的机制。
计算机电话集成 (CTI)：
我所说的 CTI 是指通过与 PBX 的数据集成进行的第一方或第三方呼叫控制。
- 特点差异。超出大多数人的想象。如果您在配备 ACD 的呼叫中心，情况可能会非常复杂。不同供应商的 ACD 功能可能有很大不同。
- 事件流/数据格式。同样，它们可能非常不同。在某些交换机上，您将获得一组丰富的事件。在某些环境中，您几乎看不到任何东西。
- 呼叫跟踪。跟踪数据弹出的交换机周围的呼叫并不总是像获取呼叫引用 ID 并使用它作为密钥将数据粘贴到数据库中那么容易。在一些交换机上，当呼叫在系统中移动时，引用 ID 会发生变化。您需要编写软件来跟踪转换并根据内部引用 ID 对其进行更新。哦，并不是所有的交换机都支持引用 ID...
总之，您不仅会看到交换机之间的差异，还会看到同一交换机不同协议、服务/配置类别甚至每个设备造成的差异。对于后者，我的意思是您可以根据座席桌上的电话设置看到不同的行为（与 CTI 数据弹出相关）。
没有单一的解决方案可以隐藏所有这些，并且考虑到一些差异，通用解决方案不可能存在。但是，可以创建针对特定用例的约束模型。这并不容易，需要大量的交换机经验来创建标准化层。
现在我已经概述了问题的更大领域（是的，还有其他问题:-( ），一些建议：
- 将应用程序逻辑与电话逻辑分离。假设您需要多个插件模块来进行电话集成。
- 避免在标准化层附近切换特定功能。如果您在座席桌面上部署，您将无法避免它们，因为呼叫中心希望您利用或至少遵守其特定的 ACD 配置（如果您的呼叫未正确显示在他们的报告中，您将面临失去客户的风险） ）
- 选择支持广泛的电话协议并提供丰富的扩展传输功能集的主要 IVR 供应商。
- 虽然标准……很差……但它们就是你所拥有的一切。使用 VoiceXML 编写您的应用程序。如果您的交换机或呼叫中心有主要供应商无法支持的交易，则可以更换 IVR 供应商。
- CTI 协议有多种。TAPI、JTAPI、TSAPI、CSTA 等。没有一个答案。有几个商业标准化层可以为您提供更一致的 API，但每个交换机的功能和事件流仍然有所不同。要么计划写入多个接口，要么付费购买第 3 方 API。这里没有简单的答案，因为第三方产品的成本可能是昂贵的附加组件，但实现各种交换机的开发工作可能会更多。
- 与有限的几家交换机供应商或 CTI 服务器合作（例如思科 ICM、Genesys T-Server）。它限制了您的市场，但最大限度地降低了集成成本。但是，这种合作伙伴关系可能会帮助您利用销售并获得更多客户。
此外，作为一种替代回答我的问题，我们已经无意中发现创建使用JTAPI提供多个电话系统（板，用户交换机和IP电话）和平台支持的接口一个开源项目。这样一来，因为我是提我可以开发一个应用程序，并已成为许多不同的系统，无论系统的工作。我肯定也有例外，但是这应该与他们大部分的工作 - 考虑到TAPI是那种广泛接受的标准的反正：
其所谓的 '通用JTAPI'：
