I have worked in this space for a number of years. ChrisW's answer is very good. Here is some additional information that may be helpful to people in similar situations.
I'm assuming you are offering a premise solution as most of your integration concerns go away if you're hosting your application. If you need to change facilities, and you isolated your telephony logic from your dialog and business logic, the translation shouldn't be too difficult.
IVR/PBX integration challenges show up in a number of ways:
Telephony:
By telephony, I mean first party call control. Features of the phone line.
Call arrival information (ANI/DNIS). Assuming you are working at a higher level, like VoiceXML, you still can have a variety of issues. Just some:
Data existence. Not all switches provide this data. What's worse, is the data may only be available with certain switch configurations. That configuration may be in conflict with other needs (transfers) of your application or the call center.
Data format. Depending on your application, this may or may not be a problem, but the format of the data can vary a bit from switch to switch.
Varying transfer types. Depending on the architecture of the surrounding telephony network, your transfer type may need to vary. Usually, the default hook-flash transfer available in VoiceXML will work when transferring to agents or ACDs in a local call center. However, off site/off PBX/PBX-PBX transfers, need to be performed as a supervised(2 step) transfer. Note, the VoiceXML standard doesn't cover this type of transfer. It only covers blind transfers and conferences, but most platforms provide a mechansim to access additional transfer logic.
Computer Telephony Integration (CTI):
By CTI, I mean first or third party call control through a data integration with the PBX.
Features differences. More than most can possibly imagine. It can be really complicated if you are in a call center with an ACD. ACD features can be very different vendor to vendor.
Event streams/data formats. Again, they can be very different. On some switches you'll get a rich set of events. In some environments, you can see virtually none.
Call tracking. Tracking a call around a switch for a data pop isn't always as easy as getting a call reference id and sticking data in a database using it as a key. On several switches, the ref ids change as the call moves around the system. You'll need to write software to track the transitions and update it against an internal ref id. Oh, and not all switches support ref ids...
In summary, you will not only see differences between switches, but same switch different protocols, differences due to class of service/configuration and even per device. On the later, I mean you can see different behavior based on the phone set on the agent's desk (relevant for CTI data pops).
There is no single solution that hides all of this and given some of the differences a general purpose solution can't exist. However, a constrained model for specific use cases can be created. It just isn't very easy and requires a lot of experience with switches to create the normalization layer.
So now that I've outlined the bigger areas of the problem (yes, there are others :-( ), some advice:
Decouple your application logic from your telephony logic. Assume you will need multiple plug in modules for your telephony integration.
Avoid switch specific features near your normalization layer. You won't be able to avoid them if you are deploying on agent desktops as call centers expect you will leverage or at least honor their specific ACD configuration (if your calls don't show up correctly in their reports, you risk losing a customer)
Pick a primary IVR vendor that supports a wide range of telephony protocols and exposes a rich extended set of transfer features.
While the standards...are poor...they are all you have. Write your application in VoiceXML. Be in a position to change IVR vendors if you have a deal on a switch or in a call center that the primary vendor cannot support.
There are a variety of CTI protocols. TAPI, JTAPI, TSAPI, CSTA and so on. There isn't a single answer. There are a couple of commercial normalization layers that give you a more consistent API, but the feature and event streams still vary per switch. Either plan on writing to multiple interfaces or paying for a 3rd party API. No easy answer here as the cost for the 3rd party product can be an expensive add-on, but the development effort to implement a wide range of switches can be even more.
Partner with a limited set of switch vendors or CTI servers (e.g. Cisco ICM, Genesys T-Server). It limits your market, but minimizes the integration costs. But, that partnership may help you leverage sales and get access to more customers.
I worked for VoiceGenie a few years ago: they made (I'm using the past tense here only because I don't know what they're doing now, not because they're no longer doing it) a VoiceXML engine, which:
Is a Linux box
Has 3rd-party Speech-to-text and text-to-speech engines connected (by interfacing with the Engine-specific APIs)
Interprets VoiceXML (using its own VoiceXML parser), and executes it by driving the 3rd-party Speech-to-text and text-to-speech engines
They hired me to interface their box to call control systems: and the first system I did that for was Cisco's (conversely, I see that VoiceGenie are now owned by Genesys). Their engine also supported non-VoiceXML applications, e.g. it exposed a Java application interface.
In conclusion:
Various phone systems have proprietary call-control APIs; and/or they may support standard call-control protocols (e.g. SIP) and/or APIs (e.g. JTAPI, TAPI, CCXML) and, if they do, do it more-or-less well.
I'm not a product manager, system engineer, network architect, domain expert in this field.
BUT they all generally support a handful of protocols and API's
Some supported only a proprietary, ad/or some support one or more standards.
So the idea is to interface to the API or protocol that is supported the most.
I'd question the business case for that, but I reckon that you ought to find and talk with a telephony engineer, who has specific domain expertise and product/implementation knowledge. I encountered what I posted above by working as a software developer, but I don't have the domain expertise.
Would that be SIP?
SIP is a protocol, not an API. This stuff is in layers, for example as an application you might use:
Lower level: a SIP protocol stack with own API; you use this API, understand what SIP dialogs look like, and talk (only) with systems which understand SIP
Higher level: a VoiceXML/CCXML engine (or a TAPI or a JTAPI engine); you write XML (or use the TAPI and JTAPI APIs); and the engine (depending on which engine it is) may have a built-in SIP stack which it uses to talk to components which use SIP, and/or it might have other protocol stacks for components which use other (non-SIP) protocols.
Cisco only had one (proprietary) protocol I could use, to talk to their "Intelligent Contact Management" (i.e. call centre) system. And Genesys I think had a closed, proprietary API/protocol.
If so then would my call control and IVR solution be best implemented as a SIP front end to a JTAPI application or some variant?
I'm confused about what you want to do, where in the stack you want to be (not that I could say anything useful if I did know).
I think that maybe you ought to be talking with vendors: to find out what they can do for you (unless you're trying to complete with them, which would be difficult).
Can you narrow down what "any potential PBX/IVR or PBX combo" means?
另外，作为我的问题的替代答案，我们偶然发现了一个开源项目，该项目使用 JTAPI 创建一个接口，为多个电话系统（板、PBX 和 IP 电话）和平台提供支持。这样我就可以像我提到的那样开发一个应用程序，并让它适用于许多不同的系统，而不管系统是什么。我确信有例外，但这应该适用于大多数例外 - 考虑到 TAPI 无论如何都是一种广泛接受的标准：
Also as an alternative answer to my question we've stumbled on an open source project that creates an interface using JTAPI to provide support for multiple telephony systems (boards, PBXes and IP telephony) and platforms. This way I can develop an application as I was mentioning and have it work for many different systems regardless of the system. I am sure there are exceptions but this is supposed to work with the majority of them - considering that TAPI is sort of a widely accepted standard anyway:
Save yourself some pain and development time with Twilio. Basically they deal with the PSTN/VOIP connection and you just tell them what to do with XML/HTTP REST. They have helper libraries in a variety of languages, including Java.
发布评论
评论（5）
我在这个领域工作了很多年。 ChrisW的回答非常好。以下是一些可能对处于类似情况的人有所帮助的附加信息。
我假设您提供了一个前提解决方案，因为如果您托管应用程序，您的大多数集成问题都会消失。如果您需要更改设施，并且将电话逻辑与对话和业务逻辑隔离，那么转换应该不会太困难。
IVR/PBX 集成挑战以多种方式出现：
电话：
我所说的电话是指第一方呼叫控制。电话线的特点。
计算机电话集成 (CTI)：
CTI 是指通过与 PBX 的数据集成进行的第一方或第三方呼叫控制。
总之，您不仅会看到交换机之间的差异，还会看到同一交换机不同的协议、由于服务/配置类别甚至每个设备而导致的差异。对于后者，我的意思是您可以根据座席桌上的电话设置看到不同的行为（与 CTI 数据弹出相关）。
没有单一的解决方案可以隐藏所有这些，并且考虑到一些差异，通用解决方案不可能存在。但是，可以创建针对特定用例的约束模型。这并不容易，需要大量的交换机经验来创建标准化层。
现在我已经概述了问题的更大领域（是的，还有其他问题:-( ），一些建议：
I have worked in this space for a number of years. ChrisW's answer is very good. Here is some additional information that may be helpful to people in similar situations.
I'm assuming you are offering a premise solution as most of your integration concerns go away if you're hosting your application. If you need to change facilities, and you isolated your telephony logic from your dialog and business logic, the translation shouldn't be too difficult.
IVR/PBX integration challenges show up in a number of ways:
Telephony:
By telephony, I mean first party call control. Features of the phone line.
Computer Telephony Integration (CTI):
By CTI, I mean first or third party call control through a data integration with the PBX.
In summary, you will not only see differences between switches, but same switch different protocols, differences due to class of service/configuration and even per device. On the later, I mean you can see different behavior based on the phone set on the agent's desk (relevant for CTI data pops).
There is no single solution that hides all of this and given some of the differences a general purpose solution can't exist. However, a constrained model for specific use cases can be created. It just isn't very easy and requires a lot of experience with switches to create the normalization layer.
So now that I've outlined the bigger areas of the problem (yes, there are others :-( ), some advice:
几年前我为 VoiceGenie 工作：他们制作了（我在这里使用过去时只是因为我不知道他们现在在做什么，不是因为他们不再这样做）一个 VoiceXML 引擎，它：
他们雇用我将他们的盒子连接到呼叫控制系统：我这样做的第一个系统是 Cisco 的（相反，我看到 VoiceGenie 现在属于 Genesys）。他们的引擎还支持非 VoiceXML 应用程序，例如它公开了 Java 应用程序接口。
结论：
我不是该领域的产品经理、系统工程师、网络架构师、领域专家。
有些仅支持专有的，有些支持一个或多个标准。
我对此的商业案例提出质疑，但我认为您应该找到一位具有特定领域专业知识和产品/实施知识的电话工程师并与之交谈。我作为一名软件开发人员遇到了上面发布的内容，但我没有该领域的专业知识。
SIP 是一种协议，而不是 API。这些东西是分层的，例如作为您可能使用的应用程序：
较低级别：具有自己的 API 的 SIP 协议栈；您使用此 API，了解 SIP 对话框的外观，并（仅）与了解 SIP 的系统进行对话
更高级别：VoiceXML/CCXML 引擎（或 TAPI 或 JTAPI 引擎）；您编写 XML（或使用 TAPI 和 JTAPI API）；并且引擎（取决于它是哪个引擎）可能有一个内置的 SIP 堆栈，用于与使用 SIP 的组件进行通信，和/或可能有其他协议堆栈用于使用其他（非 SIP）协议的组件.
思科只有一种我可以使用的（专有）协议，与他们的“智能联系人管理”（即呼叫中心）系统进行通信。我认为 Genesys 有一个封闭的、专有的 API/协议。
我对你想做什么，你想在堆栈中的什么位置感到困惑（如果我知道的话，我不能说任何有用的东西）。
我认为也许你应该与供应商交谈：找出他们可以为你做些什么（除非你试图与他们一起完成，这会很困难）。
您能否缩小范围“任何潜在的 PBX/IVR 或 PBX 组合”的含义？
I worked for VoiceGenie a few years ago: they made (I'm using the past tense here only because I don't know what they're doing now, not because they're no longer doing it) a VoiceXML engine, which:
They hired me to interface their box to call control systems: and the first system I did that for was Cisco's (conversely, I see that VoiceGenie are now owned by Genesys). Their engine also supported non-VoiceXML applications, e.g. it exposed a Java application interface.
In conclusion:
I'm not a product manager, system engineer, network architect, domain expert in this field.
Some supported only a proprietary, ad/or some support one or more standards.
I'd question the business case for that, but I reckon that you ought to find and talk with a telephony engineer, who has specific domain expertise and product/implementation knowledge. I encountered what I posted above by working as a software developer, but I don't have the domain expertise.
SIP is a protocol, not an API. This stuff is in layers, for example as an application you might use:
Lower level: a SIP protocol stack with own API; you use this API, understand what SIP dialogs look like, and talk (only) with systems which understand SIP
Higher level: a VoiceXML/CCXML engine (or a TAPI or a JTAPI engine); you write XML (or use the TAPI and JTAPI APIs); and the engine (depending on which engine it is) may have a built-in SIP stack which it uses to talk to components which use SIP, and/or it might have other protocol stacks for components which use other (non-SIP) protocols.
Cisco only had one (proprietary) protocol I could use, to talk to their "Intelligent Contact Management" (i.e. call centre) system. And Genesys I think had a closed, proprietary API/protocol.
I'm confused about what you want to do, where in the stack you want to be (not that I could say anything useful if I did know).
I think that maybe you ought to be talking with vendors: to find out what they can do for you (unless you're trying to complete with them, which would be difficult).
Can you narrow down what "any potential PBX/IVR or PBX combo" means?
另外，作为我的问题的替代答案，我们偶然发现了一个开源项目，该项目使用 JTAPI 创建一个接口，为多个电话系统（板、PBX 和 IP 电话）和平台提供支持。这样我就可以像我提到的那样开发一个应用程序，并让它适用于许多不同的系统，而不管系统是什么。我确信有例外，但这应该适用于大多数例外 - 考虑到 TAPI 无论如何都是一种广泛接受的标准：
它称为“通用 JTAPI”：
http://gjtapi.sourceforge.net/
Also as an alternative answer to my question we've stumbled on an open source project that creates an interface using JTAPI to provide support for multiple telephony systems (boards, PBXes and IP telephony) and platforms. This way I can develop an application as I was mentioning and have it work for many different systems regardless of the system. I am sure there are exceptions but this is supposed to work with the majority of them - considering that TAPI is sort of a widely accepted standard anyway:
Its called 'Generic JTAPI':
http://gjtapi.sourceforge.net/
使用 Twilio 为您节省一些痛苦和开发时间。基本上，他们处理 PSTN/VOIP 连接，您只需告诉他们如何处理 XML/HTTP REST。他们拥有各种语言的帮助程序库，包括 Java。
Save yourself some pain and development time with Twilio. Basically they deal with the PSTN/VOIP connection and you just tell them what to do with XML/HTTP REST. They have helper libraries in a variety of languages, including Java.
使用 Web/RESTful API 开发 IVR 要容易得多。有一些这样的 API 提供商。
Twilio 是美国最受欢迎的解决方案，最近也支持英国。
Hoiio 适用于香港和新加坡等亚洲国家。
It is much easier to use web/RESTful APIs to develop an IVR. There are a few such API providers.
Twilio is the most popular solution around in US, and recently also supporting UK.
Hoiio is good for Asia countries such as Hong Kong and Singapore.