Is it possible to access audio files locally to decrease del

[shoeman]

Write now our application stores its audio files behind our Tomcat webserver. Is there a way to store them locally on the Plum server to increase queuing time and reduce delays for the user? Right now when reading off a 10 digit number the application has to queue 10 audio files which means 10 HTTP calls. Is there a syntax in vxml for loading the files from disk such as file://tomcat/webapps/audio/1.wav?

[support]

1) Log on to the IVR system
2) configure and enable apache, if its not already setup
3) make a directory on the IVR system with read permissions for wwwuser
4) upload audio files to the newly created directory.
5) reference the files using the ip address or domain name assigned to the IVR system

[shoeman]

Well we already have a Tomcat instance on the Plum server. We are trying to avoid the HTTP calls, even local ones. I would rather do a file load or suggest some fast way to queue up audio files. So you didn't answer my question about being able to do local files loads from disk.

[support]

The Plum Voice Platform does support the file:// URI syntax. The syntax of your URI is simply not right. The full path of the file must follow file://, including the leading / in the path. So if your file is saved at:

/tomcat/webapps/audio/1.wav

you should use the audio src attribute:

file:///tomcat/webapps/audio/1.wav

with three slashes after the colon.

Code: Select all

<audio src="file:///tomcat/webapps/audio/1.wav">one</audio>

At Plum we have built IVR applications which require queuing many more than 10 audio files. The additional overhead of queuing files via HTTP in the absence of network latency (when we're going to a local server) is negligible in even our largest IVR applications. If you are experiencing what seems like an overly long delay before audio playback in your IVR application, the most likely culprit is the timeout set for input before the audio is queued.

If you find that making the request to the audio files through your Tomcat server does indeed introduce significant delays, then we would suggest serving the files directly through Apache instead, which we have found to be very fast. We find that application configuration management is simpler when all requests are sent through the web server.

Then send a complaint to the Tomcat development team.