Loading announcements from external webserver

[gerco]

Hi all,

I have designed and developed IVR applications for more than 15 years, mainly on Avaya products. Their current platform (Voice Portal / Experience Portal) is also based on VXML, where the application server runs in Tomcat.

Based on that experience, I went into the VAD, to see what it can do. What I would like to know at the end, is if it is possible to run VXML applications on other VXML servers than the built-in one.

I found an article here already asking a similar question, but the answer on that was that 3CX uses a proprietary way to register apps in 3CX. That is what I already noticed.

So what I tried is the following.

I created a dummy application in VAD and deployed that on 3CX. I then went into the start VXML page and edited its contents. The start VXML page should only contain a redirect to the next VXML page located on an external web server. So I changed the <form> node at the bottom, to have a <goto next="http://mywebserver.local/thenextstep.vxml" />

I can see that this node actually loads from the external web server. I needed to remove some references to prevent file not found errors, but the actual VXML page can indeed be loaded from an external web server.

The next step would be to play an announcement from this external VXML page, to see if the 3CX VXML interpreter could load an announcement using http. So in the thenextstep.vxml, I added an announcement, like:

<prompt bargein="true">
<audio src="http://mywebserver.local/helloworld.wav" />
</prompt>

Here is where it goes wrong. The webserver is an apache web server that serves wav files as an audio/x-wav mime type. When I check the IVRServer.log file, 3CX responds with:

VXIMachine.cpp(894):IvrDll, CallSession:romptUrl2File(), Error! ERROR!!!:Attempt to load as buffer: content type=audio/x-wavfrom 'http://mywebserver.local/helloworld.wav'

When I check the access log of the Apache HTTP server, I can see that the 3CX IVR is trying to fetch the wave file:

"GET /helloworld.wav HTTP/1.1" 200 120702 "-" "3CXIvrEngine/1.0 libwww/5.3.1"

However, 3CX is not playing it.

Anyone hints on how to solve this?

Thanks!!

Best regards,
Gerco

 

[VAD_Support]

Hi Gerco,

This is an unsupported scenario, the 3CX IVR has not been tested with external servers and we can't guarantee it will work.

Anyway if you want to make some experiments, I suggest you to go and check the VXML files for the IVR applications provided with 3CX (like the voicemail for example) and see how it returns the audio files. Maybe you can change your VXML app to do it in the same way.

Regards,

 

[gerco]

Hello VAD_Support,

According to the VXML 2.0 specification, the <audio> tag can point to a URI, even supporting streaming. Was the choice to use an open standard as VXML in 3CX only to provide an internal mechanism, but never intended to be used for custom development (i.e. only VAD generated apps are supported, no support for VXML generated manually or by an external server)?

The logs actually show that 3CX fetches the file from the external web server, but then fails to play it. So part of it seems to be working. Fetching actual vxml documents from an external web server does not seem to be a problem.

I was thinking of two possible scenarios. Either a distributed 3CX application that fetches dynamic messages from a centralized web server, allowing easy maintenance by a customer (daily changing announcements), or a scenario to use the power of other already existing VXML capable servers.

Anyhow, unsupported is unsupported, I understand what you are saying. I will have a look at the other IVR apps to get a feeling on how stuff works.

Thank you for your fast response.

Best regards,
Gerco

 

[VAD_Support]

Hi Gerco,

I'm not saying that it will not work. It will probably work. But we can't guarantee it will work, because the 3CX IVR has not been tested in that scenario.

VAD applications don't use "http://". They use "file://" instead in order to load local files. But maybe the other VXML apps use a different approach, that's why my suggestion about checking them.

Kind regards,