Hello Everyone
 
I have a customer who has cvp servers in Europe and VXML gateways in Asia. The delay when i ping, round trip time is about 200ms.
 
I have a big delay for the realisation of cvp_subdialog_start, and subdialog_start element.
 
Icm calls primary application which is named viplooku
Between the start and exit state of that application there is 2 and more seconds delay, as seen in CVP activity log
 
viplookup flow calls subfow named dbaccesssf which chekcs if the db connection is available. at the beginning of that subflow there is subdialo_start element. in cvp logs i have 3 secnods between the start and exit of this element, although it does nothing.
 
when i was watching vxml debug on vxml gateway i saw that for loading vxml page for the cvp_subdialog_start of the first, viplookup application, there 1.8 seconds loading,
for the loading of the subdialog_start of second flow there is also arround 2 sec process for loading of the page by the vxml gateway.
 
All this with starting icm script and dbquery within the both flows. causes to me some 10 seconds pause before the first prompt which is later played by icm when viplookup finishes
 
is there any way to shorten this, by setting some parameter or similar, or this is just naturally because of the size of vxml ages and big latency in the network
 
Thank you, Vojislav
 
 

If anyone at Cisco is listening, they could easily simplify the
VxmlServer root document and cut down on this delay time for ALL THEIR
CUSTOMERS!

Right now, the VXML Server creates a root document that catches about 40
different events. Most of them are prefixed with 'error.'

They should just replace all of these <catch> tags with one that catches
the generic <error> event and pass back the name of the actual event
that was caught.
This would cut a lot of the time delay by making the page smaller.

Since almost every event is handled the same way, it's crazy for them to
waste space and time with the large root document.

Vojislav,
If you're willing to use a customisation then there is something you might want to try.  If you delay answering the call and do it explicitly from the Studio application after the root document and initial setup steps are completed rather than immediately when the VRU leg is setup, the caller will just hear a bit more ringback.  At the point you answer the call, the root doc will have been served and the TCP window size should have widened also.  The customisation involves commenting-out the command to answer the call in bootstrap.tcl and use of a custom element or VoiceXML Insert to explicitly answer the call at the point required in the application.  The attached doc shows the delayed answer principle in a slightly different scenario.  Let me know if you need more information.
 
Janine,
Have you ever tried setting <setting name="vxml_error_handling">minimal</setting> in the gateway adapter as detailed in the SRND.
 
Geoff,
Why wait to be asked?  There's no guarantee that things will get done but you should feel free to use the forum for feedback.
 
Paul

Attachments:

Geoff,
Yes, alternative way may be to use microapps. However VXML apps do not necessarily need to be slow. However a lot depends on your design and architecture of your backend app and especially where stored procs need to be run or across different countries. Studio app is nothing but a combination of vxml and java where applicable. If you design your backend well, I do not see any reason for delay as listed below.
There are several replication strategies that could be employed.
Hemal

From: Cisco Developer Community Forums [mailto:cdicuser@developer.cisco.com]
Sent: Saturday, September 08, 2012 2:48 PM
To: cdicuser@developer.cisco.com
Subject: New Message from GEOFFREY THOMPSON in Customer Voice Portal (CVP) - General Discussion - All Versions: RE: New Message from Vojislav Jovanovic in Customer Voice Portal (CVP) - Ge

GEOFFREY THOMPSON has created a new message in the forum "General Discussion - All Versions":

--------------------------------------------------------------
Vojislav,

>>>just naturally because of the size of vxml (p)ages and big latency in the network

Essentially, yes.

I have a customer deployment with CVP servers in central Europe and branch offices in Europe, Asia (Korea, Japan etc) and even further in Australia. I was using a CVP VXML application to do a database lookup in Europe (a custom Action Element running a complicated stored procedures) but when I used this for the Asian branch offices (added later in the rollout) the delays were unacceptable – as you have found.

I changed it to run a simplified version of lookup using ICM DBLookup and the delay was removed.

The big problem is Studio apps. The first page VXML sent by the Studio app is large, and over large distances, causes the delays you have noticed. The solution is to change to microapps only. To do your lookup you need to switch to ICM DBLookup, or use the ICM App Gateway.

You will never be able to avoid delays with Studio apps. You must change them.

Regards,
Geoff
--
To respond to this post, please click the following link:

<http://developer.cisco.com/web/cvp/forums/-/message_boards/view_message/6461146>

or simply reply to this email.