CallXML 3.0 Development Guide Home  |  Frameset Home

  Voxeo File Manager  |  TOC  |  Cache Manager API  

Caching Tips and Techniques

Voxeo uses hardware-based caching servers to speed up document requests. Typically, HTTP requests from the Voxeo infrastructure made to your web server take less than 100ms, which does not add any measurable delay to your voice application. Even on the best access provider's networks, however, latency times can sometimes reach more than 300ms (or timeout completely). This type of latency can cause your audio files to stutter or introduce extended pauses at various points in your application as dialogs are traversed. How silly will you feel with Mel Tillis performing your voice talent?

Let's look at pretty pictures

The way to reduce network latency between our network and yours is to store frequently requested objects closer to the Voxeo network. Voxeo uses a hardware-based caching architecture similar to figure A below:

In general, a cache server sits between a web server and a web browser. It acts as an intermediary in the web page loading process, invisibly accepting a request from a browser on behalf of the web server containing the actual content. This caching server watches all requests for web pages and audio files which comes past, and saves a copy for itself under certain circumstances (described below). If there is another request for the same object, the local copy can be used, instead of asking the web server for it again. Like all caching methodologies, this can dramatically improve performance.

Most modern web browsers actually have software-based cache servers built-in. They do their job so well, most of us don't even realize they are there. The cache server watches all requests for web/XML pages and audio files which come through it -- when something juicy scuttles by, a copy of this request will be saved (again, under certain circumstances). Re-fetches are then "lightning" fast for subsequent re-fetches of the document. This interaction is depicted in Figure B, using very swift looking bolts to illustrate our point:

Now stop for a moment and think about the Voxeo network. Because Voxeo is an infrastructure provider it's natural to think of Voxeo.Net in terms of servers. In reality the Voxeo.Net infrastructure is actually a network of browsers. When you call into Voxeo, our voice browsers are actually making outbound requests to your web server(s). The resulting document fetch is then presented (i.e., a user interface) to the telephone user. Notice the similarities between the caching interaction of Voxeo (Figure C) versus the caching interaction of your standard web browser (Figure B) above. Notice also how often we have used the word "notice" thus far in our tutorial.

So if caching is so transparent, you may be asking why we need a long-winded tutorial, full of corny links, to discuss it. The short answer is that cache servers are great for applications which are "code complete" and ready for production. They allow a deployed application to run smoothly, even in the face of internet latency, hurricanes, floods, and living dead. By default, all documents and audio files are cached indefinitely by Voxeo caching hardware -- that's right, our cache boxes are Napoleonic about this stuff. Once we got it, we keepin' it! For applications "under development", of course, this default behavior can be frustrating to work around.

Take the following example: Document A has been completed by a developer. He dials into the Voxeo infrastructure where Document A is fetched from the customer's web server. This document is then stored in the hardware cache. The ambitious developer, pleased with her first run of the application, decides that a couple of changes are in order for Document A. With changes in place, she calls back into Voxeo where a request for Document A is made again. Voila! This time, Document A is found in the hardware cache, obviating the need to return to the web server where the updated version is waiting. Performance is excellent but all subsequent changes to Document A have been circumvented by the cache server. In fact, short of manually clearing the cache box by a network administrator, your web server will never again be asked for Document A. Someday, we hope to have the entire internet cached in our server!

There are several ways around this caching dilema, all of which involve HTTP header manipulation. HTTP headers are meta-tags that get passed every time an HTTP request is made. Every web server passes these HTTP headers which tell a browser how to handle the content it receives in the body of the request. Below is an example of the HTTP headers being passed by Microsoft Internet Information Server 5.0.

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Cache-Control: no-cache
Expires: Fri, 07 Dec 2001 23:34:20 GMT
Connection: close
Date: Fri, 07 Dec 2001 23:34:20 GMT
Content-Type: text/xml
Accept-Ranges: bytes
Last-Modified: Fri, 07 Dec 2001 20:04:41 GMT
ETag: "9cd56754d837c11:96b"
Content-Length: 632

Notice in particular the Cache-Control: and Expires: headers. They are the key to controlling the actions of Voxeo's hardware caching servers. Recall that every request made by Voxeo's voice browsers passes through the cachebox. What the cachebox sees in the returning HTTP headers determines what the cache server does with the document. If you configure your HTTP Cache-Control header as "no-cache," our voice browsers will always return to your web server for the latest documents. Additionally the HTTP Expires header can provide you even more granular control over how-long a document should remain in the cache. By setting the Expires header to a fixed point in time, you can control how long a document remains in the cache. After the time you specify, further fetches for the document will come from the web server rather than the cache.

Specifics for Webservers and Scripting Languages

Disabling caching in IIS

Choosing to disable your caching at the server level ensures all file types (xml/script files and audio content) will be non-cacheable. From your IIS Manager properties box, choose the HTTP Headers tab. Check the "Enable Content Expiration" box and choose "Expire Immediately." No more caching headaches! When you are ready to move to production, just change these settings to something more appropriate.

Apache 1.3

Apache ( uses optional modules to include headers, including both Expires and Cache-Control. Both modules are available in the 1.2 or greater distribution.

The modules need to be built into Apache; although they are included in the distribution, they are not turned on by default. To find out if the modules are enabled in your server, find the httpd binary and run httpd -l; this should print a list of the available modules. The modules we are looking for are mod_expires and mod_headers.

If they aren't available, and you have administrative access, you can recompile Apache to include them. This can be done either by uncommenting the appropriate lines in the Configuration file, or using the -enable-module=expires and -enable-module=headers arguments to configure (1.3 or greater). Consult the INSTALL file found with the Apache distribution.
Once you have Apache setup with the appropriate modules, you can use mod_expires to specify when objects should expire either in .htaccess files, or in the server's access.conf file. You can specify expire from either access or modification time, and apply it to a file type or as a default.

See for more information, and speak with your local Apache guru if you have trouble (he will be the pasty white dude with long, unkempt hair). To apply Cache-Control headers, you'll need to use the mod_headers module, which allows you to specify arbitrary HTTP headers for a resource. See

Here's an example .htaccess file that demonstrates the use of some headers.

.htaccess files allow web publishers to use commands normally only found in configuration files. They affect the content of the directory they're in and their subdirectories. Talk to your server administrator to find out if they're enabled.

### activate mod_expires
ExpiresActive On
### Expire .gif's 1 month from when they're accessed
ExpiresByType image/gif A2592000
### Expire everything else 1 day from when it's last modified
### (this uses the Alternative syntax)
ExpiresDefault "modification plus 1 day"
### Apply a Cache-Control header to index.html
<Files index.html>
Header append Cache-Control "public, must-revalidate"

Note that mod_expires automatically calculates and inserts a Cache-Control:max-age header as appropriate.

Disabling caching in Tomcat

Write a jsp filter as described in  For the sake of illustration, we will assume that we wish to cache a VoiceXML grammar, with the '.gsl' file extension. Create a jar file for your filter class and copy it to the WEB-INF/lib directory of your servlet.  Then edit the WEB-INF\web.xml file and add the following:

<param-value>Expires: Fri, 30 Oct 1998 14:19:41 GMT</param-value>


Change the class name from orj.jspwebstuff.ResponseHeaderFilter to your class's name.  Two caching parameters are defined that turn off caching. Cache-Control (HTTP 1.1 only) limits caching to 0 seconds.  Expires (HTTP 1.0 and up) causes immediate expiration of the resource.  The filter is only applied to *.gsl files; change this as needed.

Be aware that caching disabled in script can only be done on XML dialogs and therefore is not effective for audio files. Here are a series of code snippets to disable caching:

Disabling caching in Active Server Page Code

<% response.expires = -1
response.CacheControl = "no-cache"
%><? xml version="1.0" ?>

Disabling caching in PHP Code

header('Cache-Control: no-cache');
print('<?xml version="1.0" encoding="UTF-8" ?>');

Disabling caching in Cold Fusion Code

<cfheader name="Cache-Control" value= "no-cache">
<cfheader name="Expires" value="#Now()#"><? xml version="1.0" ?>

An Additional Point About Expiration Tags

Voxeo has found that caching with specific date/time headers may not be correctly honored if your web-servers are not synchronized with Network Time Protocol (NTP). NTP is a fancy internet protocol that harmonizes a computer's/server's current time with that of several secret Atomic clocks warehoused in Namibia. For a more exhaustive exploration, you may want to check out this Slovenian guide to all things computer-time-related.

Voxeo.Net is time synchronized to Greenwich Mean Time (GMT), which is sometimes referred to as UTC time. If you have gotten inconsistent caching results, the problem may be that simple fiend that haunts us all:  time.

Other useful NTP links include:


In summary, caching is important in the architecture of your voice application. It provides a level of responsiveness that is necessary when working across the Internet. It is also an outstanding buzzword to impress your mom with when she asks you what you do all day in front of the computer. When properly configured, caching can be controlled at a fine level. Server level caching requires much less configuration, works on audio files and is the quickest way to move a development application to production. Which method you choose is up to you, but it is always best to decide and configure a method of cache-control prior to beginning any coding of your application.

Additional Resources

An excellent resource for all things HTTP caching related can be found at The wise web and phone markup author will familiarize herself with everything contained therein.

0 posts - click the button below to add a note to this page

  Voxeo File Manager  |  TOC  |  Cache Manager API  

© 2013 Voxeo Corporation  |  Voxeo IVR  |  VoiceXML & CCXML IVR Developer Site