How IVR play the audio file that is on the server B

[vincent.zheng]

I have an IVR app in Server A, Server A can access Server B, the audio file is on the Server B on port 8099.  In server A, if I open the file in IE, it can download the file and play the file. But once come into IVR, IVR cannot play the audio file and throw out error.badfetch. What might be causing that?

My boss is thinking IVR will download the file into some random temp folder in Server A, and IVR just grab the file from there to play, but IVR does not have access to that temp folder, is it possible that this situation happen?

[janinegraves]

What error are you actually seeing in the Activity/Error log?

error.badfetch usually indicates that the gateway timed out waiting

for the the response to an HTTP request - so perhaps it's taking too

long for the audio file to be returned from the remote media server. You

can set the timeout in the gateway: http client response timeout

(followed by the # seconds).

Or you can set it in the Studio application within the application as a

VoiceXML Property

Name: fetchtimeout Value: 10s

If you're getting *error.badfetch.http.404 *then it indicates a missing

audio file.

[vincent.zheng]

the error log for ivr is only error.badfetch...

Is it possible that the ivr is in server A machine, the gate way in server c, and server c get the file from server b then back to server A to play?

[janinegraves]

The servers aren't retrieving or playing the audio files. The VoiceXML

Gateway tries to retrieve the audio file and play it to the caller.

Perhaps the gateway doesn't have the ability to retrieve the audio file

from the server (or perhaps it takes too long).

[janinegraves]

The "IVR" that you are talking about is really the Call Server and VXML

Server - but they just create the command to retrieve and play the audio

file.

The VoiceXML Gateway's "http client" process actually tries to retrieve

the audio file and play it to the caller.

[Gerry O'Rourke]

You can see what the HTTP error you are getting on the VXML Gateway (I assume you are using IOS and not VVB?) by using the command "debug ip http client error".

Maybe the hostname is not added to the Gateway?

If the VXML server is "severing up" a wav file location of "http://mediaserver/en-us/app/blah.wav" the VXML gateway needs to be able to resolve the hostname "mediaserver".

this can be added by using the below command:

ip host mediaserver 123.123.123.123

Gerry

[vincent.zheng]

right now we think VXML Server right now does not have access on Server B. Will see after they open the firewall for VXML Server

[k-martell]

Vincent,

     I think there is still a bit of confusion as to how the calls progress through CVP. Let me see if I can add a some clarity here. When the call comes into the environment it will terminate on a GW of some sort. This is just the beginning, now you need the following, a VXML server, a VXML Client (voice browser), and a MEdia Server. Depending on your deployment, the VXML Client (Voice Browser) may be located on a GW or it may be virtual. Sounds from what I am reading yours resides on a GW. It is that GW that is actually processing the call. The CVP Servers you refer to as Server A and Server B, are there for 2 reasons, the first is to serve up VXML to the GW so that it may process the call. The second task it seems you are using from these servers is to be your Media Server. Do NOT confuse your MEDIA SERVER with your VXML Server. The VXML server is only the VXML that needs to be processed, it does not get tied to the media server in any way unless the application developer does so in their code.

With that said, it sounds like you may have a call landing on GW A, using CVP Server A for VXML and still have something pointing over to CVP b for media.

you should be able to tell from the VXML GW where the prompts are being played from by looking at your cache. In order to validate that your GW can reach and see all your pormots do the following.

1. run "show http client cache" on the vxml GW. This will show you all the prompts loaded on that GW. Verify you see prompts fro the Media Servers you expect.

2. in order to test that you can load prompts from both locations issue the following command.

"audio-prompt load" followed by the full http path to your prompt. for example

"audio-prompt load http://10.0.0.1/en-us/app/ccmusic.wav"

Do this for each of the Media servers. If the prompt does not load successfully there is a problem between your GW and that media server. If both prompts load properly then your issue is elsewhere.

Just for clarity, what version and deployment model are you using?

[vincent.zheng]

CVP is 10.5(1)

UCCE is 10.0(1) Build 1662

  Cisco IOS Software, C3900e Software (C3900e-UNIVERSALK9-M), Version 15.2(4)M6a, RELEASE SOFTWARE (fc1)

[k-martell]

in your ICM/UCCE script, what do you have the ECC Variable "user.microapp.media_server"  set to?

[vincent.zheng]

Let me do more clarification on this,

For example IP for VXML server is 12.12.123.1, my IVR app are located in 12.123.123.12, all the audio file that IVR needs to play the menu is in 12.123.123.12:80/en-us/app/Project1/, but in my IVR, I also use TTS, which means the audio file that dynamic generated the TTS, is located in http://12.12.12.12:8099/TTSFolder/, so in my IVR, the webservice just return the whole url link, for example http://12.12.12.12:8099/TTSFolder/test1.wav, and in the audio element, I just put the link back, and uncheck the use_default_path.

So in ICM/UCCE script, user.microapp.media_server need to be set to two location? I think 12.123.123.12:80 is set on the media_server since I didn't do the ICM part...

[vincent.zheng]

The issues currently fixed. Seems like the VXML server doesn't have access on the external server