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

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

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

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

呼叫到达信息 (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) 合作。它限制了您的市场，但最大限度地降低了集成成本。但是，这种伙伴关系可以帮助您利用销售并获得更多客户的访问权限。

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

是一个 Linux 盒子

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

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

他们雇我来连接他们的盒子来调用控制系统：我做的第一个系统是思科的（相反，我看到 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 组合”的含义吗？

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

它被称为“通用 JTAPI”：

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