CVP Problem puling a prompt file from media server.

Unanswered Question
Oct 31st, 2008

Guys,

I had an issue today where my VXML Gateways had a problem refreshing a prompt after the expiration on it expired. When I did a

'debug http client error' I saw that it was looking for mediaserver-backup in the path of the failing prompt. For some reason it thought it wasn't on the Local CVP server and was trying to fetch it accross the WAN.. I could manually refresh the prompt with audio-load prompt <filename> from the local CVP but if I tried refreshing from the backup I got an incorrect Audio format error thing.

After this I repeated everything from the other side and it was functioning fine . I chopped up the file (it was the biggest one 1.6meg) into smaller and it was fine.

I did notice that it had a timeout message in the error at Timeout 4000MS. Is there a way to expand this timeoutin IOS someway?

What I don't understand is why it wasnt looking for the original mediaserver path, and why it had worked for a long time prior with no problems. It seems like when the VXML gateway pulls from the mediaserver-backup once, it will always look there for future tries, instead of trying mediaserver the subsequent time.

IOS 15.4(15)T7

Any insight would be great!

Thanks,

Chad

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
geoff@hp.com Sat, 11/01/2008 - 14:21

Chad, have you read the Cisco white paper on the HTTP Client Cache? If you cannot find it, email me and I'll send you a copy. It's mandatory reading. ;-)

>"It seems like when the VXML gateway pulls from the mediaserver-backup once, it will always look there for future tries, instead of trying mediaserver the subsequent time"

Those instructions don't come from the gateway, they come from the Call Server. If it's in the cache and not stale, it plays from the cache. If the fetch fails, the Call Server adds "-backup" and reissues the instructions.

I seem to remember that there was something in the early versions of CVP that worked like you mentioned. If it failed to reach the Call Server through "isn-vxml" then it locked onto the "-backup" and used that until it failed. Not sure if media files were done the same way, but possibly. I believe Cisco changed this for CVP 4.x though.

You were wise to chop it up - keep 'em small.

Regards,

Geoff

Chad Stachowicz Sat, 11/01/2008 - 20:35

Geoff,

I think that it hasn't been fixed in CVP 4.0(2). Maybe that was fixed in 4.1? Anyways I was unable to find that doc, so if you could email it to me at cstachowicz@touchbase.us that would be awesome.

Thanks!

Chad

Chuck Smith Sun, 11/02/2008 - 06:34

Starting with CVP 4.X the isn-vxml host record is no longer used. When the vxml gateway starts the bootstrap it connects to the originating IP of where the call came in on. This is because the gateway asumes that the callserver that initiated the call will be up since it started the processes. After that the callserver instructs the gateway where all of the other callservers that are out there. Something like that. :)

As for the media server. Even the 7.X SRND says that if the primary media server fails it will switch to the -backup media server and continue to use it until it fails. I would assume this is to prevent any further delay in future calls that come in.

geoff@hp.com Sun, 11/02/2008 - 11:25

Something like that. Yeah. The old distributed ideas from ISN fell away - app server lists, VBs and app servers separated etc. What you say is correct, but can be over-ridden by specifying "cvpserver" (or something like that) as a param to the application.

"Even the 7.X SRND says that if the primary media server fails it will switch to the -backup media server and continue to use it until it fails"

OK, always good to check the SRND. Thanks.

The only reason I made this comment was that Cisco had discussed changing the way that system worked. Many deployments prefer one side to the other, especially if the "B" side is some sort of Disaster Recovery/Business Continuity site. Obviously there are advantages and disadvantges to both techniques. Then there is always a pair of CSS 2-packs if you've got some money to throw at the solution (why are those things so bloody expensive?).

(White paper sent to those who asked).

Regards,

Geoff

Chuck Smith Sun, 11/02/2008 - 12:47

There should be some way to set a timeout for it to retry the primary again I agree. CSS......who ever heard of using those!!!! :)

I personally think it should be that way for exactly the setup you are talking about. DR sites and what not.

I was not aware about the application param. I will have to look into that. Thanks.

Chris Deren Tue, 05/05/2009 - 14:36

Guys, I am experiencing a similar problem where the prompts do not play when -backup server is used, even though I can resolve this hostname and I have the prompts on the media server, is this not suppose to work?

Here is what debug http show:

000159: *May 5 22:27:45.660: //3//HTTPC:/httpc_cache_store: No cached entry (0x49D76DA4) found for http://mediaserver-backup/en-us/app/LKQ/SC_COL_Greeting.wav

Chris

geoff@hp.com Tue, 05/05/2009 - 20:06

For sure this works, mate.

That trace snippet does not look like an error - that looks like the file is not in the cache, which may be expected. Now it will fetch it.

Turn up trace on the Call Server and watch the action there. You should see the VXML page made up using the "mediaserver" and sent to the gateway, and then it getting the VXML error that the WAV file would not play. So the Call Server appends "-backup" and makes up a new page, and tries again. You will see this.

Silly question. In the early days of CVP and ISN, Cisco used "media" to refer to the Web server hosting the WAV files and "mediaserver" to refer to a server for external VXML files (e.g. Audium). I still use them in this form. Just checking that "mediaserver" is not your VXML box.

I assume you have two entries in your ip host table:

ip host mediaserver 1.2.3.4

ip host mediaserver-backup 5.6.7.8

and you have your WAV files located on both boxes in exactly the same location. Just try swapping the IP addresses around.

Regards,

Geoff

Chris Deren Wed, 05/06/2009 - 06:14

I am not sure what happened, but after rebooting second time it all started working again.

I have seperate dedicated media servers, and I am only using microapps, this issue started occuring only for one of the sites I have, where for some reason the files were not being cached as "sh http client cache" showed no cached files, hence the error.

After I changed my microapp to point to IP instead of mediaserver it was working fine, as soon as I changed it back to mediaserver it did not, however I was able to ping it as well as mediaserver-backup just fine.

Weird...

Chris

geoff@hp.com Wed, 05/06/2009 - 06:24

Check the content expiration on that media server (IIS? Apache?). Is it set to immediate expiration - that could explain nothing in the cache.

Regards,

Geoff

Chris Deren Wed, 05/06/2009 - 06:25

It is set to never expire (I know I need to change it), so this should not be the issue.

Chris

Actions

This Discussion