Looking into IVR software development

Question

The company I work for is looking for an IVR implementation that is highly compatible with any potential PBX/IVR or PBX combo OR to provide our own hosting solution.

So the idea would be to create an application that interfaces to any potential platform and provide call control and voice dialog / interaction for the IVR.

Technologies I've looked at so far (we would like to use Java) are Java Telephony API (JTAPI) the JAIN-JCC (Java Call Control) API and others. The basic gist of these API's make sense to me, but what I cannot put together is exactly how the application I would create for call control and voice IVR / VXML would interface in a platform independent way to the phone system. How exactly am I to get the call from the phone system?

These API's and libraries seem to leave this question unanswered which leads me to believe that a platform independent solution isn't possible and that it's always going to be implementation specific. There's also JAIN-SIP, if I can convert all calls to SIP then maybe I can create a generic call control / IVR application this way.

If I've uttered any ignorances here or misunderstandings please forgive me, I am completely new to any kind of telecom technology - anyone who wants to set me straight? I'd be very very grateful, the connections on the detail implementation level are very very fuzzy at this point and sometimes I need a little hand holding. Any help or pushes in the right direction would be helpful.

I've been pouring over specs and API's for the last week. :)

EDIT - I've forgotten to mention that we prefer to develop this in house if at all possible and smart in terms of cost/benefit - not really looking to spend money on a integrated platform if at all possible - thats my job :)

Answer 1

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.
• You might find 3rd-party engines (e.g. the Genesys Voice Platform, the Microsoft Office Communications Server, and others) which give you some unified API, and handles and supports (or, not) the interop with other components.

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?

Answer 2

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/

Answer 3

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.

Answer 4

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.