After changing fetchtimeout to 60s about 10% calls are getting discoonected with system error message.

[Hossain Ahmed Ashfaque]

Hi,

Due to bad fetch error. we changed fetchtimeout to 60s based on cisco doc wiki (http://docwiki.cisco.com/wiki/Unified_CVP:_VXML_Server_-_Resolving_%22badfetch%22_Errors)”

For applications Root Doc Settings VXML Property = fetchtimeout and value 60s lots of called failed about 10% in 600 calls. Also CVP applications unable to failover to secondary database if primary database is not available.

Here I filtered one log for you, with

Note: By setting VXML Property and value to system default there is no error. We tested with more than 1000 calls. Also CVP applications able to failover to secondary database if primary database is not available.

Wondering how come fetchtimeout default value (7s) works better than extended value 60s also why the fetchtimeout value has an impact on database failover.

I attached the logs herewith.

CALLGUID = 6965DDD144AF11E58234C471FE13E000

[janinegraves · Accepted solution]

First, you probably should NOT set the fetchtimeout to 60s in the root document - it dictates how long the gateway waits for the response of every http request - both audio files and vxml pages. So, in the root document you should set fetchtimeout to something relatively short, like 7s.

Then in whichever Voice element (Audio, Digits, anything with a square shape on it) that comes immediately before the slow function in the application, in its Settings tab, set the fetchtimeout to something large, like 60s. You'll also want to set the VoiceXML Property named fetchaudio to a URL pointing to some music to play to the caller (fetchaudio CAN be set in the root doc; or in the Voice element).

Without seeing the actual root document settings from Studio (or the VXML Logs or the gateway 'debug voip app vxml error' logs) one can't tell you why fetchtimeout of  60s in the root doc would cause calls to fail. UNLESS you actually had  configured  the fetchtimeout in the root document to 60 (omitting the s, for seconds) --- the system defaults to MILLISECONDS if you omit the time unit of 's'  from the value.  This is true for all the VXML Properties (except audiomaxage).

Note that error.badfetch is also thrown by the VXML Server if the web services element isn't waiting long enough for the web service to return a value. But, usually then you'll see more information in the error log (other than just seeing error.badfetch).

[Hossain Ahmed Ashfaque]

Hi Janine,

Thanks, I configured the fetchtimeout in the root document to 60 without s. I was not aware that by default is uses miliseconds.

Based on your suggestion we should keep the fetchtimeout short in the rrot document setting which is 7s by default. You also mentioned that we should use this setting in audio element just before the slow function in the application.

In my application I have few database check. And one of them is in the beginning of the callflow to check holiday dates. For this how to increase the fetchtimeout value. I attached the sceenshot from the application. Kindly have look. In the screen shots i highlighted the database check options in red oval.

Kindly let me know if the below setting is not correct.

Thanks,

Ashfaque

[janinegraves]

Hi,

This all looks correct now.

If the first DB query might be slow, you should probably use an Audio

element between the CVP_Subd_Start and the DB query to set the

fetchtimeout timer. You have to play 'something' in an Audio element, so

you could use the silence_.1_sec.wav from the system prompts folder. But

be sure that you set *fetchaudio *VXML property to a URI to play

'something' to the caller so they know the call is still alive.

[tauqeer.nasir1]

Thank you very much for your valuable reply. Do you have any idea that how we can change fetchtimeout property in end class? My scenario is that, when a call ends, I want to hit API which may take more than 60 seconds. So my root setting is 10s but I want to increase this time while ending the call (In End class). 

Thanks,

Touqer

[Lili Chan]

hi,

Ive a follow-on question if you dont mind ....

For the VXML Server global config file - "ip_redirect" tag. Currently, this has been enabled to "True" whereas Default is "False".

However, the deployment is not using Load Balancers, rather its using DNS SRV. My question is upon enabling "ip_redirect" to True, what does this imply ?

[ip_redirect—This tag enables a feature that redirects the gateway to point directly to the VXML server, which circumvents any load balancers that may lie between the gateway and server. This tag uses a VoiceXML goto with the explicit IP address of the server for the first VoiceXML page of a call. When this feature is enabled, the VXML server uses a load balancer only for the first HTTP request of a call session, but not for subsequent requests for the same call session. The tag, if used, takes a required attribute active which can be true or false. It also takes an optional attribute, ip_to_use, which contains the IP address to use for a redirect if you do not want to use the IP address returned by the default VXML server.]

Thanks, lili

[Gerry O'Rourke]

Lili,

Would be best to open a new query for this query, as its not really a follow on query, i.e. different topic.

The IP redirect purpose is to remove the content switch from the call flow, which makes a slot of sense.

Its not needed once the VXML server has been selected. It reduces load on the content server and if the VXML server failed during the call, the call could not seemlessly start in the middle of a call on the alternative VXML server anyway.

It replaces the hostname with the IP address so would also work with DNS SRV records.

http://vxmlserver:7080/CVP/Server?application=HelloWorld

http://123.123.123.123:7080/CVP/Server?application=HelloWorld

The Content Server uses cookies to make sure it stays on the one VXML server for the complete call.

I don't know what DNS SRV records do. It might be a requirement to use this if you use DNS SRV records so you stick to the one server? i.e. I cannot see a negative to using this.

However my recommendation if not using a content switch is to link the Call Server, Media Server and VXML server to the same server for each individual call. It makes troubleshooting easier and makes a lot of sense as you know the server is up and removes any possibility of delay if one of the other servers is down.

Are you SURE you are using SRV records for both the SIP Call (to CVP CallServer) AND the Media / VXML server hostnames?

How to link Media and VXML server is outlined in the below URL from the SRND.

Design Guide for Cisco Unified Customer Voice Portal, Release 10.5(1) - Media File Options [Cisco Unified Customer Voic…

Note: Cisco have incorrectly set the Routing Client Names in PCCE to name which is invalid in DNS so you have to change these if using PCCE (Cisco please correct!) and this method.

Also when the call routes from a CUCM Dialed Number (CTI route point) (used for call transfers back into UCCE), the above does not work to link to the CallServer which has the call, but there are other methods to do so and I wish Cisco would fix, as the CVP info ECC variable also does not work either to find teh IP address of the CVP CallServer that is active for the call.

You can use this workaround:

cisco:uc:cvp:cvp-ip-address [Gerard O'Rourke]

Regards,

Gerry