Forcing an audio item in the VXML Gateway Cache to be refreshed

[janinegraves]

Hi,

Caching continues to be a huge issue for my students and cisco customers - in particular how to refresh a re-recorded item that's in the cache IF IT HASN"T YET EXPIRED.

I've gotten all the following commands from cisco documentation. But I've been told by students who have tried each of these, that they often fail to refresh/reload the cache, and the customer has to resort to a 'reload' command. Argh.

So, can anyone explain when/why each of the following would fail? And best practice when one needs to force one item to be refreshed in the Vxml Gateway cache before it's expired?

1.VXML Application - set the VXML Property 'audiomaxage' to '0' and speak a URI from the app

2. CLI Command: audio load <URI>

3. CLI Command: set http client cache stale

4. CLI Command: clear http client cache

Thanks, Janine

[Chad Stachowicz]

#2 that you mention is def the recommended way.

First of all if they are production installs and have 2 media servers, there is a good chance that they are not refresshing both the servers URI's.

If it doesn't work I would get the IOS version and report a bug for it.

I personally have never experienced this and have been working a long time.

If worse comes to worse just change the PromptName and update the script, and let it cache fresh, easy.

Chad

[janinegraves]

Thanks Chad. In the 2008 Cisco Client Cache Whitepaper, it says that if the audio is in use (being played to a caller) then the 'audio prompt-load ' command will not work. Have you ever experienced that? (A whitepaper from 2008 is pretty far back, so I'm wondering if it's changed)

Thanks, Janine

[geoff]

I don't believe that "clear http client cache" has been implemented.

Setting the cache to stale is pretty reliable. Make sure that your Web server delivering the wav file and the voice gateway are synchronized. 

audio-prompt load almost always works, but sometimes it does not, and I've never gotten to the bottom of it either.

The best thing for all of us would be if Cisco implemented the "clear" command to just totally drop the cache entries.

Regards,

Geoff

[janinegraves]

Thanks Geoff. The command 'clear http client cache' actually works on my gateway (15.1(3)), but it complains - "command accepted but obsolete, unreleased or unsupported;see documentation"

So, you've seen the audio load command fail? Do you think the system was playing the audio to a caller at the time?

Thanks, Janine

I don't believe that "clear http client cache" has been implemented.

[akhilesh shukla]

If none of these command works just change the prompts date created and date modified. It will get refreshed automatically.   

[Vinay K M]

set http client stale try this command to refresh the audio items on the gateway

[geoff]

Vinay Kariyappa wrote:
 set http client stale try this command to refresh the audio items on the gateway

Mmm, mentioned by the original poster. And discussed. (You forgot "cache")

3. CLI Command: set http client cache stale

Regards,

Geoff

[Ayodeji Okanlawon]

Just to add to this old thread,

On IOS 15.4 (3) CLI Command: audio load <URI> worked for me while audio-prompt load <URI> didnt work

[geoff]

One more gem just came across recently.

If the prompt is being delivered by Tomcat and not IIS, audio-prompt load does not seem to work. The example is the default Cisco Agent Greeting recording application. Prompts are held in VXMLServer\Tomcat\webapps\CVP\audio.

During a recent upgrade to 10.5 which I was observing and not the prime, an ES was applied that replaced all the WAV files in the above directory with a-law versions, so instead of hearing the prompts in the guys voice we expected we heard TTS rendering the text.

We replaced the audio files from the backup with the u-law versions and tried to force the gateway to discard the a-law ones with "set http client cache stale" and "audio-prompt load" but could not make them take. A reload of the gateway fixed the problem.

Be careful with the ES's you apply.

Regards,

Geoff

[Ayodeji Okanlawon]

Hi Geoff,

 I thought the audio load command worked but alas! how wrong I was.

After extensively troubleshooting, here is a summary of how to get new version of a prompt that has been cached on the gateway to load.

 For new prompt to be loaded from media server to vxml gateway and invalidate the media file in cache, the "modified date" on the file must be after the last time stamp on the file when when the vxml gateway cached it. Each time a file is cached the time stamp on it is passed to the gateway from IIS.

The reload/audio load process on the gateway is only a part of the picture. When the reload or audio command is used, the gateway will request the new file however it will ask the media server if the file has been modified from the last time it downloaded and cached it. If the modified date on the media file is the same, then the media server doesn’t send the file.

Here is the log proving this:

++ using the following commands +++

• audio load http://uccemedias/en-us/app/IT/1001.wav or

       config t ( service internal), exit,

• "test http client get http://uccemedias/en-us/app/IT/14001.wav reload
• debug http client all
• no debug http client socket

+++ After issuing one of the commands above to reload the cached file +++

From the output of the logs, the gateway requests the file but includes ( "If-Modified-Since: Thu, 05 Apr 2018 18:39:14 GMT")

423004: Apr 13 09:24:30.433: //149246//HTTPC:/httpc_get: url length=40
423005: Apr 13 09:24:30.433: //149246//HTTPC:/httpc_get: url: http://uccemedias/en-us/app/IT/1001.wav
423006: Apr 13 09:24:30.433: //149246//HTTPC:/httpc_send_ev: event sent to HTTP Client:
423007: Apr 13 09:24:30.433: method (GET), url (http://uccemedias/en-us/app/IT/1001.wav)
--
---
GET /en-us/app/IT/1001.wav HTTP/1.1
Host: uccemedias
If-Modified-Since: Thu, 05 Apr 2018 18:39:14 GMT
Content-Type: application/x-www-form-urlencoded
Connection: close
Accept: text/vxml, text/x-vxml, application/vxml, application/x-vxml, application/voicexml, application/x-voicexml, text/plain, text/html, audio/basic, audio/wav, multipart/form-data, application/octet-stream
User-Agent: Cisco-IOS-C2900/15.4
423022: Apr 13 09:24:30.437: //149246//HTTPC:/httpc_socket_send: fd: 0
423023: Apr 13 09:24:30.437: //149246//HTTPC:/httpc_socket_send:
423024: Apr 13 09:24:30.437: about to send data to the socket 0 : first 400 bytes of data:
GET /en-us/app/IT/1001.wav HTTP/1.1
Host: uccemedias
If-Modified-Since: Thu, 05 Apr 2018 18:39:14 GMT
Content-Type: application/x-www-form-urlencoded
Connection: close

+++ Media server responds with 304 not modified, and doesn’t send the file, so gateway continues to use the old file in its cache +++
423027: Apr 13 09:24:30.441: //149246//HTTPC:/httpc_socket_read:
423028: Apr 13 09:24:30.441: read data from the socket 0 : first 400 bytes of data:
HTTP/1.1 304 Not Modified
Cache-Control: no-cache
Accept-Ranges: bytes
ETag: "0353365dcdd31:0"
Server: Microsoft-IIS/8.5
Date: Fri, 13 Apr 2018 09:24:30 GMT
Connection: close

 +++ Conclusion +++

To force a cache file to reload, you have to ensure that the modified date on it is after the date the gateway last cached the file ( in this case 5th of April).

NB: The IF modified time is the time on the file on IIS. When the gateway downloads the file, the time is passed to it and when it tries to reload the file, it will always check with IIS if this time has changed.

oof! Who would have thought loading new prompt could be so much of a hassle!