>>> as I'm assuming it's getting cached on some of the VXML gateways.

It certainly is.

Caching time (also called expiration time) is controlled by the web server. If you are using IIS, check Content Expiration time. This can be controlled at the folder level, and inheritance applies, but a sub-folder can override the parent.

You probably want these recordings to go into a special folder. You can set “Expire Immediately” on the folder and then no files will be saved in the http client cache on the gateway. Take care in doing this because it has a huge impact in performance and only apply it if that is absolutely necessary. Even a modest expiration time of 1 hour will be a vast improvement over “Expire Immediately”. You cannot just leave this blank, or the default on the cache will apply – that’s normally 10 days.

But if you want it to work immediately, you have no choice here – set “Expire Immediately” on the folder where the recordings are. If the recordings are mixed in with the other prompts for which caching is required, it ends up being very messy. So a dedicated folder/directory is my recommendation.

In a similar application I created a small FTP class to FTP the file to each of the media stores. There is a Cisco element available in CVP 8.5, but at the time I had to create a custom class.

By the way, there is NO really good reason to have 4 media stores. Just have 2 – one at the A side and 1 at the B side.

Regards,
Geoff

Hi,

Note that Geoff is correct about setting the Expiry times on the Media Server, but that'll only take effect after audio URLs currently in the gateway cache expire!

If the audio URL is already cached on a vxml gateway and it hasn't expired yet, then the gateway doesn't bother to check with the media server to see if there's a newer version.

The VxmlGateway only checks for updates when the URL that's cached has expired (the age is greater than the FreshTime when you execute 'show http client cache') AND the audio is suppoed to be spoken to a caller in a VXML page.

So, even if the audio file is the same on your media servers, it may not have expired yet on one or more gateways, so you'll still hear the old audio.

To force the vxml gateway to check for a newer version of an audio URL, you can try these CLI commands
Option a) 'show http client cache' (look at the age of the audio you want to change)l then execute 'audio-prompt load <URL>' CAUTION - this always claims to be successful, even if it hasn't updated the cache because the audio file is in use). Then execute 'show http client cache' again and see if the age of the audio has gotten smaller - if so, good. If not, try the next option.

Option b) Use the CLI command 'set http client cache stale' - this sets everything to stale, there's no way to set one audio URL to stale. Thenfor each audio to be spoken, the gateway checks to see if the 'last modified date' on the media server is newer than what's in the cache. Only downloading audio with new 'last modified date'.

Janine

So basically unless the cache is expiring the vxml gateway will not look for a new version of the audio file correct and it will be updated as each cache expires? I found out that our gateways are set to refresh at a certain time/length to accomdate for other applications so it looks like I'm kind of stuck. Unless, as Bill was saying, I can get the files to upload to all 4 media servers, but then again, if the file already exists, it won't look for a new version until the cache expires is what I'm understanding.

It's another 3rd party application that is also caching files on the vxml gateways. Not sure if that helps...

Unless you absolutely need immediate exp'n, i wouldn't do that, but just.
Set it to a very low value (like 1 minute). I believe that if a file can't
be cached, then the gateway must retrieve it for each caller. But, if it is
in cache and has expired, then gateway does conditional get and checks
w/media server for updates, retrieving the audio only if it has newer
last-modified date. Much less bandwidth usage.





Sent from my Verizon Wireless Phone

-----Original message-----
From: Cisco Developer Community Forums <cdicuser@developer.cisco.com>
To: "cdicuser@developer.cisco.com" <cdicuser@developer.cisco.com>
Sent: Tue, Mar 27, 2012 15:11:00 GMT+00:00
Subject: New Message from Bill Webb in Customer Voice Portal (CVP) - General
Discussion - All Versions: RE: App not playing recorded wav file
consistently

No.

Sent from my Verizon Wireless Phone

-----Original message-----
From: Cisco Developer Community Forums <cdicuser@developer.cisco.com>
To: "cdicuser@developer.cisco.com" <cdicuser@developer.cisco.com>
Sent: Tue, Mar 27, 2012 16:08:17 GMT+00:00
Subject: New Message from GEOFFREY THOMPSON in Customer Voice Portal (CVP) -
General Discussion - All Versions: RE: New Message from Janine Graves in
Customer Voice Portal (CVP) - General

I'm curious about this as well, because the way I believe it to work is that once the header indicates the content is expired, the file is downloaded again, regardless of the last changed time stamp.

Certainly it would be more intelligent if it operated the way you describe, and maybe that is the case - I've not done debugs either and don't currently have a system to test that with.

Can anybody else confirm or deny?

- Bill

Janine,
Just to add. There is more logic to it.
When a audio file is first downloaded from HTTP server and HTTP header contains the message:

Cache-Control: max-age = < >

then this will be used to determine the stale time of the audio file. If this is not included then difference between expiration date and current date time is used to determine if the file is stale. If even this information is not present then fresh time is taken as 10% of the difference between last modified time and date. In case even this is not present in header we can assign it using :
http client cache refresh ( between 1-864000)

Also the conditional get applies to only non streaming mode.

Hemal






From: Cisco Developer Community Forums [mailto:cdicuser@developer.cisco.com]
Sent: Tuesday, March 27, 2012 2:04 PM
To: cdicuser@developer.cisco.com
Subject: New Message from Janine Graves in Customer Voice Portal (CVP) - General Discussion - All Versions: Re: New Message from Bill Webb in Customer Voice Portal (CVP) - General Dis

Janine Graves has created a new message in the forum "General Discussion - All Versions":

--------------------------------------------------------------
The http cache whitepaper 'claims' the 'conditional get' with only
downloading 'if last modified date' is newer. Can anyone confirm?

Sent from my Verizon Wireless Phone

-----Original message-----
From: Cisco Developer Community Forums <cdicuser@developer.cisco.com>
To: "cdicuser@developer.cisco.com" <cdicuser@developer.cisco.com>
Sent: Tue, Mar 27, 2012 17:59:21 GMT+00:00
Subject: New Message from Bill Webb in Customer Voice Portal (CVP) - General
Discussion - All Versions: RE: Re: New Message from GEOFFREY THOMPSON in
Customer Voice Portal (CVP) -
--
To respond to this post, please click the following link:

<http://developer.cisco.com/web/cvp/forums/-/message_boards/view_message/5364327>

or simply reply to this email.

Hi Paul,
Does the vxml property 'audiomaxage' override this? That is, if a file in
cache is not yet stale but a file is to be spoken with the audiomaxage
property set to 1 (or 0), will that cause the gw to act as if the cached
version is 'stale'?

Sent from my Verizon Wireless Phone

-----Original message-----
From: Cisco Developer Community Forums <cdicuser@developer.cisco.com>
To: "cdicuser@developer.cisco.com" <cdicuser@developer.cisco.com>
Sent: Wed, Mar 28, 2012 00:04:02 GMT+00:00
Subject: New Message from Paul Tindall in Customer Voice Portal (CVP) -
General Discussion - All Versions: RE: Re: New Message from GEOFFREY
THOMPSON in Customer Voice Portal (CVP) -

Janine,
 
Yes, that's correct, the fresh-time that's been set by the Cache-Control header won't be affected but the audiomaxage value you set will be tested against the current age in cache and a prompt refresh attempt will be made if age-in-cache > your audiomaxage value.