Plum IVR Support

This question is very similar to the post found here: http://support.plumvoice.com/viewtopic. ... hing#p4838

We are having problems with our audio files never being cached, resulting in excessive traffic to our web servers. We have tried manipulating the HTTP headers that come back on an audio request. Following is an example of the returned headers:
So the cache-control as well as the expires are set. Then, within our script we have the following settings in our application root document:
Even with that set we were still seeing cache misses on every request, so we followed the advice given in the thread that I referenced earlier. So an example audio tag would look like:

Even with the audio tags explicitly stating the maxage, our logs still show:
And the exact same three lines show up again for the next cache miss less than 5 seconds later as the audio file is re-used.

Is there something that we are missing from what you can tell on either the server side or within our code?

Thanks!

Hi rquant,

Regarding your caching issues with these audio files, do they have the same settings as other audio files that are being used in your application? We've seen a Cache Hit for filename, data_process.wav.

Regards,
Plum Support

They do not have the exact same settings, no. The data_process.wav is actually from a test that we did after I started this thread to determine that very thing. The data_process.wav exists next to the scripts themselves and is served as static content in the web root of our server.

The other audio files actually exist in different folders that are chosen at runtime depending on the DNIS that is called. So we serve these files through a servlet in a tomcat web application that inspects the URL and does some work in the background to determine where the file should be served from. It then sets the appropriate HTTP headers and streams the file just as the web server would be doing if it were a direct reference to a file in the web root. Since the URLs look just like any other file to the VoiceXML interpreter, I didn't think that this would have an effect on the caching, but I guess that must be the culprit.

So the question becomes: is there no way to cache the files without making sure that they are directly accessible through a server providing static content instead of a servlet that dynamically serves files?

Thanks.

Hi,

We've looked further into this issue and have found two issues of why your audio files may not be caching.

1) The first issue is that we have multiple IVR servers running your application, thus resulting in multiple caches. All of these caches need to be filled before there's a cache hit that avoids your web server.

2) The second issue is that the maxage is set to 1000 seconds, which is 16.6 minutes. So, you would need to call your application multiple times within those 16.6 minutes so that multiple servers are hit and give a greater likelihood of hitting the cache on one of those servers.

Please let us know if this improves the caching of your audio files.

Regards,
Plum Support

Thank you for the additional investigation work. I did not realize that there were multiple caches that would need to be hit, but I don't believe that could be the issue.

The reason for that is: we are seeing the same audio file have a cache miss several times in a single call. We have several very short files that are played before every options (a good example here is the word "for"), so we request "For.wav" at least 4 times each call that we have tested and seen these cache misses on. It would seem that this would not be affected by the distribution across different servers or the relatively short max-age, because they are certainly occurring within 16 minutes of eachother.

We will continue investigating other possible solutions, but would certainly welcome any other advice.

Thanks again!

After spending more time investigating alternative solutions to the caching problem, I am still having issues getting our files to appropriately be cached by the PlumVoice servers.

I have updated our end to serve these static files through NGINX instead of streaming them through a tomcat servlet. Now a header from one of the files looks like the following:
So you can see that the expires and cache-control headers are set for one hour.

Then in the VoiceXML I have this at the top of the application root file:
Additionally, to make sure all bases were covered, the audio tag I'm testing looks like this:
Then the output from the PlumVoice call log is:
And again, that file shows up multiple times in the same call, and every time it is a cache miss, so I don't think it can be related to having multiple servers with independent caches.

Now, we do still have one file that I am seeing a cache hit on, but it is one that is in the same directory on our server as the scripts themselves and is therefore referenced with a relative link instead of a fully qualified URL. When doing a fetch of the headers for testing, it gives back:
So it is actually missing some of the headers that I would expect to be required for caching, but is still cached even when my other files are not. It is also the fetch audio file, not directly used in an audio tag.
So as far as I can tell, the thing difference between my files that are being cached and those that are not is that the ones that are always getting cache misses are being referenced with a full URL instead of a relative link. This is a necessity for our application.

We really need to solve why files are not being cached, because we can't sustain serving the full file for each request. Any insight you could provide would be very much appreciated.

Hi rquant,

We've run a couple of tests on your audio files and believe that the issue is being caused by the headers being set for MainMenu.wav.

Here is the script that we ran on 3 audio files:

audiotest.php:
Audio test #1:

Audio file used: audio file stored on one of our internal servers, amorpm.wav

curl -I http://<full URL>/amorpm.wav
HTTP/1.1 200 OK
Date: Thu, 07 Jul 2011 15:55:15 GMT
Server: Apache/1.3.41 (Unix) PHP/5.2.13 mod_ssl/2.8.31 OpenSSL/0.9.8e-fips-rhel5
Last-Modified: Thu, 07 Jul 2011 15:38:15 GMT
ETag: "e6913b-8a94-4e15d2e7"
Accept-Ranges: bytes
Content-Length: 35476
Content-Type: audio/x-wav

Call Log:

bargein set to true
INPUTMODES set to "DTMF VOICE"
Cache Miss: http://<full URL>/amorpm.wav
Attempting to fetch http://<full URL>/amorpm.wav
Audio segment from the URL http://<full URL>/amorpm.wav added to prompt queue
bargein set to true
INPUTMODES set to "DTMF VOICE"
Cache Hit: http://<full URL>/amorpm.wav
Audio segment from the URL http://<full URL>/amorpm.wav added to prompt queue
bargein set to true
INPUTMODES set to "DTMF VOICE"
Cache Hit: http://<full URL>/amorpm.wav
Audio segment from the URL http://<full URL>/amorpm.wav added to prompt queue
starting playback: bargein=true, inputmodes="dtmf speech"
Newly queued prompts are now being played

Audio test #2:

Audio file used: data_process.wav

curl -I http://<full URL>/data_process.wav
HTTP/1.1 200 OK
Server: nginx/0.7.67
Date: Thu, 07 Jul 2011 16:03:00 GMT
Content-Type: audio/x-wav
Connection: keep-alive
Accept-Ranges: bytes
ETag: W/"118808-1309984225000"
Last-Modified: Wed, 06 Jul 2011 20:30:25 GMT
Content-Length: 118808

Call Log:

bargein set to true
INPUTMODES set to "DTMF VOICE"
Cache Miss: http://<full URL>/data_process.wav
Attempting to fetch http://<full URL>/data_process.wav

Thu 07 Jul 2011 12:11:13 PM EDT:
Audio segment from the URL http://<full URL>/data_process.wav added to prompt queue
bargein set to true
INPUTMODES set to "DTMF VOICE"
Cache Hit: http://<full URL>/data_process.wav
Audio segment from the URL http://<full URL>/data_process.wav added to prompt queue
bargein set to true
INPUTMODES set to "DTMF VOICE"
Cache Hit: http://<full URL>/data_process.wav
Audio segment from the URL http://<full URL>/data_process.wav added to prompt queue
starting playback: bargein=true, inputmodes="dtmf speech"
Newly queued prompts are now being played

Audio test #3:

Audio file used: MainMenu.wav

curl -I http://<full URL>/MainMenu.wav
HTTP/1.1 200 OK
Server: nginx/0.7.67
Date: Thu, 07 Jul 2011 15:55:37 GMT
Content-Type: audio/x-wav
Content-Length: 8638
Last-Modified: Thu, 16 Jun 2011 20:40:18 GMT
Connection: keep-alive
Expires: Thu, 07 Jul 2011 16:55:37 GMT
Cache-Control: max-age=3600
Content-Disposition: attachment; filename=MainMenu.wav
Accept-Ranges: bytes

Call Log:

bargein set to true
INPUTMODES set to "DTMF VOICE"
Cache Miss: http://<full URL>/MainMenu.wav
Attempting to fetch http://<full URL>/MainMenu.wav
Audio segment from the URL http://<full URL>/MainMenu.wav added to prompt queue
bargein set to true
INPUTMODES set to "DTMF VOICE"
Cache Miss: http://<full URL>/MainMenu.wav
Attempting to fetch http://<full URL>/MainMenu.wav

Thu 07 Jul 2011 11:58:05 AM EDT:
Audio segment from the URL http://<full URL>/MainMenu.wav added to prompt queue
bargein set to true
INPUTMODES set to "DTMF VOICE"
Cache Miss: http://<full URL>/MainMenu.wav
Attempting to fetch http://<full URL>/MainMenu.wav
Audio segment from the URL http://<full URL>/MainMenu.wav added to prompt queue
starting playback: bargein=true, inputmodes="dtmf speech"
Newly queued prompts are now being played

As a suggestion, try removing the extra headers from your MainMenu.wav file to see if there's an eventual Cache Hit on that file when you dial into your application.

Hope this helps.

Regards,
Plum Support

I removed the additional headers that I was adding for the file and was still seeing cache misses on every request. Then I investigated the headers from your server as well as those being returned from our Tomcat instance (which we were hoping to not use in production for these static files) and noticed that there was an additional tag being included in those where the cache hits were coming from. It is the "ETag" header.

Can you confirm that your caching servers are respecting the ETag header to determine when to update the cache over the Expires or other Cache-Control headers? It appears as though NGINX does not support generating this tag (from what I understand it provides a hash of file information), so this will cause an issue in our current solution.

Thanks.

Hi rquant,

We have escalated this issue with our engineering team and they are looking into this issue of the ETag header and caching.

Once we have an update from them, we will let you know as soon as possible.

Regards,
Plum Support

Hi rquant,

We have checked with our engineering team and they have confirmed that an ETag header must be returned in the HTTP response in order for the audio file to be cached.

Regards,
Plum Support