Showing results for 
Search instead for 
Did you mean: 

Can CVP Call Studio force VVB cached sound file to stale?

I have a simple CVP Studio app that is used to record an ad hoc message that plays when our operations are impacted by weather or technical events. 


When the business stakeholder calls the app, it plays the current ad hoc message, indicates whether the ad hoc message variable is active or inactive and then allows the caller to record a a new message. It then FTPs the new message to the two CVP media servers. 


The issue we're running into is that, oftentimes, once the new message is recorded, the cached version on the VVBs are playing instead without checking for a newer version. 


What I think is happening is that playing the existing message first is putting that version of the sound file into the VVB cache, and in cases where the ad hoc message hasn't been activated in a while, it's given the full 12 hours of freshness. I was under the impression that there should be a check performed by the VVB to see if there is a newer version of the file before relying on the cached copy, but that does not seem to be reliably working. 


I know that Cache-control exists in http, but all references I can find indicate that it's in the http header of the html file. Is there a way to embed a cache-control command to set-max-age or expire or something into the http request URI for the existing wav file (e.g., http://mediaserver/en-us/app/adhoc.wav?Cache-Control:max-age=0) and will VVB respond to it so that when the UCCE script calls the wav file in a microapp during the normal call flow, it forces VVB to grab the newest version the next time it gets called?


ETA: Apologies! This is using Cisco Unified Call Studio 11.6(1) and VVB and UCCE 11.5.1 and CVP 11.5(1)


Alternately, is there a way to leverage the VoiceXML Property section of the Audio element in CVP Studio to set this flag to stale when we call the existing wav file?

Rising star


I think that the solution for you is something that I wrote here in the past:


If you're using IIS, it'll guide you how to change the cache-control. 

Anyway, in my old post I showed that I'm changing it to 1 second. But I wouldn't recommend that. I'd tell you to put something like 3-5 minutes at least. That way you'll have to wait only 3-5 minutes till the message refreshes on VVB.


Thank you for your reply! If need be, I can try to move the ad hoc announcements into a new folder that has its own cache-limiting headers, but I'm really only looking to invoke cache expiration through the ad hoc message recording Studio app, not every time the message is called from a microapp. Additionally, I really only need a method that would enable control of ad hoc messaging and not impact the remainder of our generally stable messaging.


Unfortunately, I've never found a way to do this programmatically and have always relied on IIS or Tomcat for cache settings. Your use case is exactly where a programmatic way of marking files as stale would make a ton of sense.




You can set the vxml property named audiomaxage to an integer representing seconds where it'll assume it's stale if the Uri has been in cache longer than this. This can be done in the settings tab of the audio element.

You can use a variable passed from icm or elsewhere to make it small for a few minutes, then make it a normal value.

Not sure if it works with VVB but easy enough to try it.


Thanks @janinegraves! I think you mentioned this during class and I forgot it. I'll try it out and report back. 


Unfortunately, that doesn't seem to have any impact on the VVB cache. I still have to manually set the stale flag to Y to forced the vvb to pull down the new file if there's an existing version in cache. 


Thanks for the update. Here's something that you could try. The VB
usually only caches things that are static. If the URL contains a
question mark then it's not static.
So you could 'try' playing  adhoc.wav?aaa     (where aaa could be
IIS will ignore the ?aaa
And hopefully it'll force the vb to retrieve the audio file adhoc.wav.
Again - worth a try!?

Thank you again, Janine. I tested this and, unfortunately, it still caches a version of the file, disregarding everything after and including the "?"