10-14-2019 10:48 AM - edited 10-14-2019 10:56 AM
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 11.5.1.10000-60 and UCCE 11.5.1 and CVP 11.5(1)
10-14-2019 10:54 AM - edited 10-14-2019 11:37 AM
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?
10-14-2019 11:54 AM
Hi,
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.
10-14-2019 12:43 PM
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.
10-15-2019 06:15 AM
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.
david
10-15-2019 06:42 AM
10-15-2019 09:59 AM
Thanks @janinegraves! I think you mentioned this during class and I forgot it. I'll try it out and report back.
10-22-2019 02:43 PM
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.
10-22-2019 03:30 PM
11-15-2019 02:15 PM
Thank you again, Janine. I tested this and, unfortunately, it still caches a version of the file, disregarding everything after and including the "?"
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide