I've recently developed a new CVP application, which uses a custom decision element to make two synchronous web service calls, followed by an series of audio prompts.
The call occasionally ends abruptly. It seems to coincide when the first of the two webservice calls takes some time (longer than 3 seconds) to receive the response. This delay isn't normal expected behavior, however I don't think it's directly what's causing the issue. The log indicates that the call flows through to whichever element is next and then receives the error, disconnecting the call from cvp and dropping it back to the ICM environment.
Can anyone point me in the right direction to better analyze what's happening in the flow to resolve the issue? Also is there some documentation on this specific exception somewhere. We're using cvp8.5 at the moment.
Any help would be great!
It could well be that the gateway is timing out and throwing an event -
but that would usually be logged as an error.badfetch event.
If this is the case, then you should set the VoiceXML Property named
fetchtimeout to a value such as 20s - do this in the Audio element
immediately before your web service calls. The gateway will revert back
to its default 'http client response timeout' when the next voice
You should also set the VoiceXML Property named fetchaudio to a value
that points to a URI of an audio file to play during the delay.
I will give that a shot. This application is called by sub dialogue invoke, therefore, do I need to set the fetchtimeout in the calling app? or insert an audio with silence prior to this and set the fetchtimeout there?
Is the fetchaudio used to play a sound like the percolating sound during the delay?
What is the timeout set in the web service code ?
When you execute a Subdialog Invoke - it sends a VXML page to the
gateway to invoke the subdialog application.
I'm pretty sure that if you set the fetchtimeout before executing the
SubdInvoke - that it would no longer be in effect while the gateway
executes the invoke. You'd have to set it *within *the SubdInvoke
element (and Studio doesn't let you do that).
So, you should set *fetchtimeout *in your Subdialog application.
Add an *Audio *element in the subd application right before going to the
In this element
a) set the *fetchtimeout *and the *fetchaudio *in the settings tab.
b) you have to enter something in its audio tab, so either play
silence_.1_sec.wav (it's in the en-us/sys directory) or play a short
Yes, the fetchaudio is where you can specify to play the percolating
sound, or some other music. It has to be a full http string so the
gateway can retrieve and cache it.
There's also a VXML property named fetchaudiodelay that you can set to
*2s *so the fetchaudio music doesn't start playing unless there's been a
c) The important thing is that you're telling the gateway not to 'time
out' and to play filler music to the caller (which will be interrupted
as soon as the next vxml page is sent to the gateway).
d) I'm not sure this will solve your problem - as the error when the
gateway times out is error.badfetch --- but, it's important to have
these VoiceXML Properties set anyway.
e) As Hemal mentioned, you should check that your webservice timeout is
long enough to accommodate for the longest delay that might occur.
I just looked at the SubdialogInvoke element in Studio and I see that you CAN set the VoiceXML Properties within it.
So, you can set fetchtimeout, fetchaudio, and fetchaudiodelay in the SubdialogInvoke element. See the snapshot below.
BUT - if your subdialog app speaks to the caller before (or after) going to the webservice - then timeouts go back to the gateway default unless you also set them in that Audio element.
The receiveTimeout setting is at 60000 millis and connection is at 30000, so I think they're plenty long. I'm trying a couple of the items that janinegraves mentioned and we'll see what happens.
Usually you want the *fetchtimeout *that's in the root document to be
*10s *(or shorter?) so you know that the application is progressing
It's only *immediately *before you perform a slow back-end interaction
that you want to temporarily set the *fetchtimeout to be large (60s*).
Then after the slow web service, the next VXML page that goes to the
gateway (*audio element *or Menu or Digits or Form, etc) causes the
*fetchtimeout *to revert to that in the root document.
The fetchaudio and fetchaudiodelay can definitely be put into the root
Also, in the main application (that has the Subdialog_Invoke element
within it) -
Under *Project / Properties / Call Studio / General *-
ensure that the Session Timeout is long enough for the entire
subdialog application to execute
I usually set it to 3 or 5 Minutes - don't leave it at 30 minutes!
It's an inactivity timer - for a 'hung' license. Each voice element (eg,
audio, menu, digits, form, subdialog_invoke) has that amount of time to
complete before VXML Server frees the license because it assumes the
call's gone back to ICM.
So it has to be long enough for the entire Subdialog application to