Vxml

[Guest jabaltie]

I'm looking for :

 

1) A VXML interpretor, that is, a software that can retrieve VXML pages from servers abroad and play them.

 

2) Also, would like something that could run on my desktop, with a single simple and cheap fax/modem but , also, something that could run on a middle server, with a set of say 8 single fax/modem cards and, moreover, that could also run on a more professional server, say with Dialogic boards.

 

Is VoiceGuide the software I'm looking for ? If not, has anyone else heard about something similar ?

 

Thanks in advance for your cooperation !

[SupportTeam]

a software that can retrieve VXML pages from servers abroad and play them.

VoiceGuide does not do this at this stage. Note that when you do things this way you expose yourself to problems stemming from delays in vmxl retrieval, internet access etc. So generally when using this approach there are more points of failure and the system needs to do a lot more work per call to retrieve and interpret the VXML on the fly, so systems using this architecture usually can support fewer lines/calls per server.

would like something that could run on my desktop, with a single simple and cheap fax/modem but , also, something that could run on a middle server, with a set of say 8 single fax/modem cards and, moreover, that could also run on a more professional server, say with Dialogic boards.

VoiceGuide can do all of the above.

 

Please see our WWW from where you can download the fully working evaluation version of the software.

[Guest jabaltie]

VoiceGuide does not do this at this stage. Note that when you do things this way you expose yourself to problems stemming from delays in vmxl retrieval, internet access etc. So generally when using this approach there are more points of failure and the system needs to do a lot more work per call to retrieve and interpret the VXML on the fly, so systems using this architecture usually can support fewer lines/calls per server.

 

I understand that. However, if I were you, I would also consider some other points :

 

1) Usually the companies already have all of their corporate information on Internet/Intranet. So, it is very likely that the information they would like to expose on their IVR systems is already available on the Internet/Intranet. And, changing a page from html to vxml is a matter of formatting only (and http header too). Because of that, the integration of IVR to the legacy systems on the companies out there is smoother.

 

2) The number of professionals that work with web pages is pretty higher than those ones that deal with IVR systems. So, if you had the platform VXML, "everyone" that works with web pages could also work with VoiceGuide. No matter what the company uses, if it is PHP/ASP/JSP or whatever. The "sendability" of your product is pretty higher because you can integrate to anything.

 

3) I also would not need to buy other software licenses to run you IVR system. For instance, my database connections would be shared amongs web-requests and the IVR calls. All of the other softwares I already have installed on my web system I could reuse with the IVR. Also, I would reuse all of the stuff that I already have for web systems. For instance : on my web platform, when there's an internal error, I send an email to the developer. I even have an AUTHORY sub-system, so that I can find out to whom I need to send the email (more than 4000 scripts). All of this would be re-used within the IVR. I would not need to re-invent the wheel, that is, adapt the AUTHORY sub-system to the IVR platform.

 

4) I could mix OSes. For instance, I could keep on my web running on Linux and still have your platform on other OS, very likely on other machine, that is, on another server.

 

5) As for the problem of perfomance, I understand and I'm also afraid. However, there are also some consideratons : one could run the IVR on the same machine as the web-server thus using localhost (127.0.0.1) as address. That would minimize the traffic problem. Other things : the IVR SHOULD cache audio files so that if one needs to play it again, it already has it at hand.

 

6) Some intelligence within the IVR could also minimize the perfomance problem. For instance : our current IVR system runs in Clipper (!) but, it has some nice features : I keep my audio files on a RAMDRIVE, so that I can play them fastly. We dont have a database. Instead, ALL of our corporate data is stored on a mainframe. Sometimes the mainframe may be slow. Then, when I make a query to the mainframe and the answer is taking more than 10 seconds, my IVR plays automatically : "Wait a minute please". It's not this speech but something similar in Portuguese. When the mainframe is fast, the answer is played right away. I imagine this could also be done on the VXML platform.

 

7) Using VXML, I could enhance or improve or even change the IVR withouth the need to rewrite all of the application systems. The ring/phone on hook/play/listen particular stuff would be inside the IVR itself and not on my commercial systems.

 

8) I imagine I could also use the same VXML pages for VOIP in the future.

 

Well, this is all. I'm still strongly suggested by a VXML platform, as you can see and I'm trying to convince you to adopt it too.

 

See ya !

 

Thanks for your help !

[Guest Buzby]

I'm agreed in principle on the benefits of VXML, I quite like the fact that it allows for a physical separation of the database and IVR server which increases redundancy and reliability.

 

I know this might be a bit of a tall order, but it is feasible that someone could write a VoiceGuide script that interprets VoiceXML and so effectively allows legacy VXML applications to run without modification to the VG server.

 

Probably lots and lots of VBScript modules, but it might be a useful application if someone can spare the time to write it...

[Guest jabaltie]

Some more thoughts :

 

1) Finding a XML parser - piece of cake - tons of products out there

 

2) Making a server that retrieves VXML URLs and calls the parser - again - easy. May have some difficulty when considering httpS but, not a big deal.

 

3) After parsing the VXML document, UNDERSTAND it. Here comes the difficult part. One needs to understand , that is, a human needs to understand the VXML specs and then translate it into VoiceGuide calls.

 

I think the problem is on #3.

 

As for doing #1 and #2 above, I could do it myself. I also could find other available libraries to deal with the telephony out there but, understanding the VXML specs and implementing all of its features, this is the challenge. And it is not a task to be done by one person , like me. It should be faced by a company, like VG, that would have N clients out there using all of the different aspects of VXML, play/listen, speech recognition and so forth.

 

Maybe a shortcut would be to Google out for some free source code of a VXML parser. Motorola seems to have a good one.

[SupportTeam]

We will probably start supporting VXML reading from remote web servers at the same time as supporting Speech Recognition in downloadable version of VG.

 

Making of http calls to retreive database results can be done right now from within VBScript modules and MSXML objects can now be used within VBscript to parse the returend XML data and allow this information to be used within VoiceGuide. Using WebServices from within VBScript module is easy as well.

[Guest jabaltie]

Excelent.

 

I think this would enhance your product a lot. It will be one more selling option, I mean, it will help you to reach other markets.