IVR Solutions

This section of our technical library presents information and documentation relating to IVR Solutions 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..

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

By Robert Richardson, Computer Telephony

Wireless may be the future, but we can't help but notice that when it comes to convergence, wireless is mostly clueless. Sure, you can use WAP to get data, but you can't use the phone part of that phone while you're surfing. Save your co-browsing till you get home to your DSL connection, pal.

Converged wireless is coming, no doubt, whenever 3G (that is, fast-data-enabled) wireless comes. Or at least it'll look converged - it's still an open question whether digital voice will ever wind up in the same sorts of packets as data when both are beamed out to handsets. In any case, you'll be able to talk via your Bluetooth headset while scrolling through your daily appointments on the handset.

Some existing systems, in fact, already halfway manage the synchronous voice and data trick. Nextel, (Reston, VA - 800-639-8359) for instance, offers a voice-over-packet mode (they call it "direct connect") that can be kept open even if the phone is switched over to data mode. The catch here is that the phone can only be in one mode at a time. There are also other limitations to the current Nextel offerings, one being that the packet-based direct-connect mode is only available in a Nextel subscriber's home network; if you roam, you revert to regular digital voice service, even where your roaming service is provided by Nextel.

Left-hand Syndrome

Even with both voice and data channels open, a wireless application protocol data session has no idea how to keep track of what it is that is going on in the voice channel. The left hand doesn't know the in-process transactions of the right hand, to paraphrase the biblical wisdom, nor does the right hand monitor the packets of the left.

Say, for instance, that a voice call has been placed to a voice browser service like Tellme (Mountain View CA- 650-930-9000) or BeVocal (Sunnyvale, CA -408-907-3200). The user who places that call will be engaged in an IVR menu, in a session in which they browse the newfangled "voice Internet." On the telephony server side of the transaction, the session will be driven by a script written in VoiceXML. Even if our hypothetical user could seamlessly switch over to their next-gen service's data mode without having to drop the voice call, and even if they could browse over to an implementation of the same application using their phone's built-in microbrowser, the WAP version would be blithely unaware of the voice menu process that's underway on the same device. It would be nice if our user could avoid having to tell the system all the things that they just entered into the system using numerical keypresses.

The problem in a nutshell: If we have a device that allows more than one mode of interface, it stands to reason that we ought to be able to use the input modes interchangeably. Or, as a minimum, the underlying protocols enabling those interfaces ought to make it possible for developers to support multi-modal interfaces by explicitly hand-coding options for different kinds of input and output into the same application (see diagram).

Right now, the two protocols figuring most visibly in the wireless arena - WAP and VoiceXML - don't provide hooks to each other. Still, that's likely to change, and it's a good thing, too, because multi-modal seems like a nearly no-brainer way to make mobile applications a lot more appealing to mobile consumers. In this article, we take a look both at what WAP and VoiceXML don't do right now, how they're likely to learn how to live happily with each other, and at how at least one savvy vendor is already working to deliver some pretty sexy near-convergence scenarios.

Equally Oblivious

Why is it that WAP can't handle phone calls better, given that it's whole raison d'etre is to make a cell phone more usable? The most obvious answer is that it's a young standard, still in transition (an obvious fact that plenty of critics have been far too quick to overlook when dishing out anti-WAP broadsides). As things stand, WAP conveys its "web pages" to mobile handsets using WML (wireless markup language). We took a close look at this markup standard back in June of last year (Mobile CT: The Call of the Wireless Web), but the salient point here is that the only thing the current rendition of WAP knows how to do with regard to voice calls is to initiate them. A user can make a menu selection from a WML page (or card, in WAP parlance) and a special, built-in telephony interface (on a WML card, access to this interface is simply via a URL that begins with "wtai://" rather than "html://") drops the current WAP phone call and dials up the new number.

Although this process is appealingly simple from the WAP developer's point of view, it's pretty unworkable as soon as you entertain any kind of multi-modal scenario. First, if the user merely wants to have the next part of a menu selection process handled by voice (via VoiceXML) rather than via on-screen menu, the wait from menu selection to voice prompt is going to be unbearably long. That's because you aren't just switching gears back at the server - you're actually hanging up the call, then dialing up a new number and waiting for the call to be picked up by the telephony board on the VoiceXML server. Wireless call completion, to be perfectly blunt, takes forever.

On the more hopeful side, there's nothing about WAP that says a WAP session has to be transported via circuit-based connection. It's just that circuit-switched data connections are the standard equipment for the majority of wireless carriers right now. Look a little into the future, and the need to tie up a circuit to transfer data drops out of the picture. In either a CDPD (cellular digital packet data) or a CDMA (code division multiple access) network, the WAP interface enjoys an "always on" status (or the appearance of one - the realities of battery power dictate something closer to waiting in a sleep mode between user sessions, but the point here is that you don't have to wait for the call to go through). In general, though, in most of the U.S. today, when a phone needs to be used for voice, any WAP session in process closes and the user has a good half minute or so to wait before anything else happens.

Furthermore, when the WAP session terminates, the context of the current WML deck (that is, series of related cards/pages) is lost. Next time the user invokes the WAP browser, they'll start at their home deck.

It's irksome to lose the context of a session for a couple of reasons. First, navigating through a WAP application is slow - you've only got a few lines of options, of which only three or four are going to show onscreen at any given moment. Nor does a typical handset display have the space for much in the way of navigational aids. Once a user's gone into a process more than a couple of WAP cards' worth, they may well not remember just how they got there.