voice xml ivr service
      Database Systems Corp. BBB Business Review
   IVR AND VOICE BROADCASTING SERVICES AND SYSTEMS Home  |   Contact Us  |   About Us  |   Sign Up  |   FAQ

ivr software applications


Virtual ACD Software
IVR Zip Code Locator
IVR Vendors
Answering Systems
IVR Solutions
IVR Service
IVR Systems
IVR Development Systems
IVR Programming
IVR Customer Satisfaction Surveys
Toll Free Services
Telephone Answering Service
800 Number Services
Voice Messaging Systems

ivr software applications

Website Information

IVR Software
Hosted IVR
IVR Hosting

IVR systems interactive voice response

Custom IVR Applications

This section of our technical library presents information and documentation relating to IVR Development and custom IVR software and products. Business phone systems and toll free answering systems (generally 800 numbers and their equivalent) are very popular for service and sales organizations, allowing customers and prospects to call your organization anywhere in the country. The PACER and WIZARD IVR System is just one of many DSC call center phone system features..

What Is IVR?. An Interactive Voice Response (IVR) processes inbound phone calls, plays recorded messages including information extracted from databases and the internet, and potentially routes calls to either inhouse service agents or transfers the caller to an outside extension.

Contact DSC today. to learn more about our IVR services and IVR application development software.

The New IVR: Talking to You
Page 3

By Robert Richardson, Computer Telephony

IVR is moving off the premise and into the network. And its front and back-ends are changing - to embrace wireless, the web, and Net development models.

"So let's say you want a person to say a date. There's about 350 ways that a person can say a date. Also, if a person says February 30 or if they say Monday the 21st when Monday is the 23rd, you want to come back to them and help them get through the transaction." All the intelligence needed to get a date from a user is packaged into a SpeechObject designed specifically for date input. Nuance has created about two dozen such objects, including basic inputs for time, amount of money, basic digits, credit card interactions, and so on (see Figure 2 for how it looks when you program a SpeechObject).

Keeping COM

Because they are Java objects, SpeechObjects package their pieces together when the applications are developed and compiled. This contrasts with other component approaches, in which individual objects are compiled as executable binary code and are then allowed to "float around" by themselves, invoked (that is, executed) as needed by any applications that make use of them. The primary frameworks for this kind of object are CORBA, an industry standard for object interconnections, and Microsoft's proprietary COM architecture. It's worth noting that the two approaches are by no means mutually exclusive - Java, for example, is frequently used to create COM objects.

Elix (Montreal, QC, Canada - 514-731-3838, www.elixonline.com) is another company with a component vision, a COM vision in their case. The company itself is the result of building-block construction; it's the result of a recent merger between MediaSoft and Prima. In looking at software development, we're talking primarily about work done within the former MediaSoft (and the company name persists in the product offerings). Elix proposes an overall scheme for creating and using software building blocks - i.e., its MediaSoft Component Framework (msCF, to use the capitalization that Elix prefers).

Elix believes that IVR simply cries out for a component-based approach, according to Gabor Barta, vice president of indirect sales. "In working with developers, we kept realizing that these guys were always starting from scratch. Every time they built an application, they had to go back to zero and rewrite everything. We said, 'You know, every computer telephony application has some functions in common.' Applications all need to answer a phone, for instance. At some point or other, an application needs to offer information to the customer. And just about every application needs to transfer a call. Every IVR offers a menu. So why not just create a reusable component that offers a menu or answers a phone call, then give the developer a wizard that asks a series of questions about what the menu should say or under what conditions the phone should be answered."

The key differentiator here is this notion of a wizard - every Elix framework component has a wizard that vastly simplifies the customization of the object. Developers can, if they choose, directly manipulate the C++ code in which the components are written, but the intent is for components to be sufficiently customizable using the wizards alone. Once the components have been tailored to a specific application, the interactions among the various components can either occur through the component framework as a direct result of how the various modules have been configured, or the interactions may be programmatically manipulated using their COM interfaces. Oh, and there's one other way to manage the components: XML. Elix's msCF incorporates XML as a language for defining call flows and for setting the individual parameters of the various components (See Figure 3).

Partly to illustrate how to intertwine components and partly to build simple off-the-shelf telephony applications, Elix provides what it calls "applets" - pre-packaged, modular combinations of components that handle generic tasks such as creating a PC PBX, help desk, tele-calendar, and so on. In simple situations, these can be used as is. The wizard interface, however, makes it easy to modify the behavior of the applets without a lot of fuss or programming expertise.


The COM approach to IVR is also embraced by Denis Hamel, president of Decisif, Inc. (Montreal, QC, Canada - 514-362-7117, www.decisif.com), who sees it as an opportunity to offer ActiveX objects that are controlled by Visual Basic scripts. "Everyone knows how to write a Word or Excel macro," he says. "By pointing that kind of language at the telephony side, you make IVR development affordable and there are hundreds of thousands of people who know how to use it."

Decisif already supports Visual Basic in its ActiveX for CTI product. Actually, because this is an ActiveX implementation, developers can use any development language and environment that supports ActiveX, including Visual C++, Delphi, and a host of others. By supplying the right ActiveX objects, Decisif provides a developer with a relatively simple interface to call control functions within an already-familiar environment. Here, for example, is the function call needed to place a call:

myTeleService.MakeCall( PhoneDevice, DialNumber, callRefID)

Although the product is currently (and correctly) targeted at developers, Hamel's point is that this kind of call can be made from within the same sort of development environment that a power user would use to create a Word macro. Indeed, it would be entirely possible to make this call from within an ordinary Word or Excel macro, though it's not clear that doing so would make much sense.

Still, the next step from delivering easy access to telephone function calls, Hamel suspects, is pushing IVR right down to the individual desktop. "If the phone equipment can route to your phone, you can have your own personal setup for how you want to answer the phone and do integration with your own personal database. This kind of system could interrogate your personal calendar and answer based on your current status."

Hamel envisions PBX (or unPBX) equipment that supports some kind of virtual port that can be routed across the LAN to a user's desktop computer (See Figure 4). Making it work relies on an object-oriented environment like COM or CORBA - Decisif has done its initial testing using COM (or to be more precise, DCOM, where the "D" stands for "distributed").

At the desktop, a COM-based telephony "stub" is running and presenting the same programmatic interface that a full-fledged version of the object would provide. So an IVR application running on the desktop can request to be notified when, for example, the status of a given extension changes. The request is packaged up by the stub (this is called "marshaling" in the COM realm) and passed across the network to a full-fledged copy of the object that's running on the unPBX. The unPBX copy fulfills the request and when the status changes, the notification that it needs to send is marshaled again and passed back across the network, where the stub passes it back to the calling application. From the application's point of view, the entire transaction occurred as if the full object and the extension it was watching were there on the desktop machine.

Page [1]  [2]  [3]  [4]  [5]  [6]  [7Next Page 

Contact DSC today. to learn more about our IVR services and IVR application development software.