Plivo caches audio files specified in a <Play> XML element and Play API method based on standard client-side caching directives for RESTful communication over HTTP.
You can control whether an audio file should be cached on Plivo servers and for how long using the cache-control and e-tag response headers.
The cache-control response header
Responding with Cache-Control:no-store ensures Plivo won't maintain a local copy of the file in its cache and will always make a request to your web server for the resource. Responding with Cache-Control:no-cache will ensure that Plivo always checks to see whether the file has changed.
Responding with Cache-Control: max-age=<new max-age value in seconds> tells Plivo to use a locally cached copy of a returned audio file for a defined period of time. Plivo will consider its cached copy outdated only after the specified number of seconds (max-age value). For example: responding with Cache-Control: max-age=14400 will ensure Plivo uses the cached copy for the next four hours.
The e-tag response header
The e-tag value of a resource is typically an MD5 hash or some other fingerprint of the contents of the file.
Plivo sets the If-None-Match request header to the e-tag value of the resource in its cache, allowing your web server to respond with a new version or with a 304 Not Modified message to instruct Plivo to use its cached version. This enables a more efficient resource update check, as no data is transferred if the resource has not changed.
Every Plivo media server maintains its own local cache. Therefore, the first call landing on any Plivo media server will always result in a cache miss.