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.

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.

In order for this to work, the operating system has to intercept calls to the "foreign" subroutine, find the subroutine in system memory (it will move around as part of the normal operating system housekeeping), pass the call information to the subroutine, then perform the process in reverse when the subroutine has finished its work. Distributed COM (or DCOM) carries this process one step farther and allows the calls to transparently leave the machine in which the application has made a request, transfer the request across the network to another machine where a copy of the COM object resides, and see that the request is fulfilled at that remote location. This all happens transparently to the application as if the COM object were close at hand on the same machine.

In order for the operating system to keep track of COM objects (which are the packages containing the subroutines), COM uses a globally unique numbering system for COM objects. In order to make it possible for programs to call objects successfully over time (even though the inner workings of a given object may have been revised), each object has a published set of rules for how to call the object (its "interfaces") which must remain the same over time. Furthermore, there is one interface that all COM objects must offer, so that programs can ask questions about what other interfaces the object supports.

Generally speaking, it's COM that allows applications to use standard pieces of the operating system, COM that makes it possible to embed an Excel spreadsheet inside a Word document, and it's COM that makes technologies like ActiveX work. When an ActiveX component is embedded in a web page, for example, that implies that the user's browser will need to use COM to call the object to do whatever it's supposed to do when the page is loaded onscreen and the user, say, clicks on the object.

We can't leave the subject of COM without mentioning that much of the instability of Windows can be traced to the fact that COM is an imperfect model. First, the versioning capabilities for tracking COM objects are limited to begin with, and Microsoft leads a whole host of other vendors in routinely breaking the rules for the sake of convenience in distribution. Second, COM overlays and to some extent duplicates the versioning system of Microsoft's dynamic link library (DLL) modules, meaning that sometimes it's impossible to reconcile the demands of the DLL versioning with what should be happening to the versioning of COM objects within those DLLs. Finally, Microsoft has needed time to hone its operating systems, so that different versions of the same COM object can be correctly distinguished in memory (improvements here are one reason why Windows 2000 runs with fewer faults than earlier OS releases).