api - 研究 IVR 软件开发

Question

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

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

到目前为止，我看过的技术（我们想使用 Java）是 Java Telephony API (JTAPI)、JAIN-JCC（Java 呼叫控制）API 等。这些 API 的基本要点对我来说是有意义的，但我无法将我为呼叫控制和语音 IVR/VXML 创建的应用程序如何以独立于平台的方式与电话系统接口相结合。我究竟如何从电话系统接听电话？

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

如果我在这里表达了任何无知或误解，请原谅我，我对任何类型的电信技术都是全新的 - 有谁想要让我直截了当？我将非常感激，在这一点上，详细实现级别的联系非常模糊，有时我需要一点手。任何朝着正确方向的帮助或推动都会有所帮助。

上周我一直在讨论规范和 API。:)

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

Answer 1

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

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

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

电话：

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

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

计算机电话集成 (CTI)：

CTI 是指通过与 PBX 的数据集成进行的第一方或第三方呼叫控制。

• 特点差异。超出大多数人的想象。如果您在带有 ACD 的呼叫中心，这可能会非常复杂。ACD 功能可能因供应商而异。
• 事件流/数据格式。同样，它们可能非常不同。在某些开关上，您将获得一组丰富的事件。在某些环境中，您几乎看不到任何东西。
• 呼叫跟踪。围绕数据弹出的开关跟踪呼叫并不总是像获取呼叫参考 ID 并使用它作为键将数据粘贴到数据库中那样容易。在几个交换机上，ref id 会随着调用在系统中的移动而变化。您需要编写软件来跟踪转换并根据内部 ref id 对其进行更新。哦，并不是所有的交换机都支持 ref id...

总之，您不仅会看到交换机之间的差异，还会看到同一交换机不同的协议、服务类别/配置甚至每个设备的差异。在后面，我的意思是您可以根据座席办公桌上的电话机看到不同的行为（与 CTI 数据弹出相关）。

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

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

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

Answer 2

几年前我为VoiceGenie工作过：他们制作了一个 VoiceXML 引擎（我在这里使用过去时只是因为我不知道他们现在在做什么，而不是因为他们不再这样做）一个 VoiceXML 引擎，它：

• 是一个Linux盒子
• 已连接第 3 方语音转文本和文本转语音引擎（通过与引擎特定的 API 接口）
• 解释 VoiceXML（使用它自己的 VoiceXML 解析器），并通过驱动 3rd-party Speech-to-text 和 text-to-speech 引擎来执行它

他们聘请我将他们的盒子连接到呼叫控制系统：我为之做的第一个系统是 Cisco 的（相反，我看到 VoiceGenie 现在归 Genesys 所有）。他们的引擎还支持非 VoiceXML 应用程序，例如它公开了一个 Java 应用程序接口。

综上所述：

• 各种电话系统都有专有的呼叫控制 API；和/或它们可能支持标准呼叫控制协议（例如 SIP）和/或 API（例如 JTAPI、TAPI、CCXML），如果支持，则或多或少都做得很好。
• 您可能会发现第三方引擎（例如Genesys Voice Platform、Microsoft 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 组合”的含义？

Answer 3

另外，作为我的问题的替代答案，我们偶然发现了一个开源项目，该项目使用 JTAPI 创建了一个接口，以提供对多个电话系统（板、PBX 和 IP 电话）和平台的支持。通过这种方式，我可以像我提到的那样开发一个应用程序，并让它适用于许多不同的系统，而不管系统如何。我确信有例外，但这应该适用于其中的大多数——考虑到 TAPI 无论如何都是一种被广泛接受的标准：

它被称为“通用 JTAPI”：

http://gjtapi.sourceforge.net/

Answer 4

使用Twilio为您节省一些痛苦和开发时间。基本上，他们处理 PSTN/VOIP 连接，您只需告诉他们如何处理 XML/HTTP REST。他们有多种语言的帮助程序库，包括 Java。

Answer 5

使用 Web/RESTful API 开发 IVR 要容易得多。有一些这样的 API 提供者。

Twilio是美国最受欢迎的解决方案，最近也支持英国。

Hoiio适合香港和新加坡等亚洲国家。