Incorrect time calculation

[dorsey]

Our script sometimes returns an unexpected number for the following calculated value (xferduration) :

<var name="timestart" expr="new Date()" />
<var name="timeend" expr="new Date()" />
<assign name="document.timeend" expr="new Date()" />
<assign name="document.timelen" expr="document.timeend.getTime() - document.timestart.getTime()" />
...
<subdialog src="<URL here>" maxage="0" method="post" namelist="document.errmsg document.xferduration document.xferresult document.timelen from to reqid" />

The xferduration variable is sometimes returned within an expected range (0-1500) and sometimes a wild value such as 330972 or higher. When a large value is returned, it has a cascading effect of setting the next call's duration to a huge negative number. I have evidence that setting the call duration to a large negative number will produce a within-range xferduration result, so that doesn't seem to be the problem; that is, we don't see a correlation between setting a huge negative call duration and a large xferduration when the call ends.

Any ideas?

Thanks,
Dorsey

[support]

The IVR code there looks fine. Have you been able to reliably reproduce this IVR behavior? If you can provide steps/conditions under which this bug manifests itself, we'll be able to more readily trace the IVR issue.

Thanks!

[dorsey]

Thanks for taking a look at this. We've been trying to reliably duplicate the problem, but have not been able to yet. We appreciate having a second opinion that the code looks fine. We'll try various input combinations to see if we can reliably produce these odd results.

Because the xferduration variable reports the time spent on the second leg of a successful call, we can probably estimate that using 2+ years of historic data at 20-30 seconds less than the total call length, but it would be better to sort this problem out.

Dorsey

[dorsey]

Is the link in the previous reply valid? When I try to open it with Firefox, I'm asked to download a new ActiveX object, which I won't do unless there is a compelling reason. The larger issue is that rather than posting a link that purports to explain something, please include a synopsis of what the link refers to so readers can determine whether it's worth following or not without having to actually follow it, just posting a magical link is of little value. That particular link itself provides no hints as to what it refers to, and I don't have time to crawl down ratholes of dubious value.

[support]

There was an IVR link posted earlier that we deleted because it came from a spammer. Good thing you didn't install the ActiveX control. Sorry about the confusion.

[dorsey]

That's what I suspected; thanks for confirming it.

[dorsey]

We found a way to duplicate this problem. When we set a call duration greater than 1200 seconds and the call itself lasts longer than 60 seconds, the xferduration variable returns a very large number. If the call lasts less than 60 seconds, a reasonable number is returned.

When the call duration is set to 1200 seconds or less, the actual call duration has no effect on the results, and the script returns a reasonable value.

For full disclosure: we tested using preset maximum call durations of 780, 1200, 1440, and 1500 seconds for historical reasons. When these latter two values are used, the VXML script will return incorrect results, but only when the call lasts longer than 60 seconds.

Please let me know if I can provide any more information. As a reference, I've include the transfer tag that sets the call duration below.

<transfer name="T_1" dest="tel:+12018359707';ani=2123307609" bridge="true" cond="true" connecttimeout="60s" maxtime="1500s" />


Dorsey

[support]

This is just what we need. Thanks! We've got some of our IVR engineers looking at and we'll let you know what we find out shortly.

[support]

Would it be possible for you to post more of your IVR code here? At first we presumed xferduration was simply a variable to which you assigned the "duration" shadow variable of your <transfer> tag. Unfortunately, we can't reproduce the IVR problem you're describing when looking at that shadow variable. Can you post IVR code showing how/where you're assigning the xferduration variable?

[dorsey]

I have some code snippets early in this post, but that might have been misleading. Here's the entire script:

<?xml version="1.0"?>
<!DOCTYPE vxml SYSTEM "http://vxml.plumgroup.com/vxml.dtd">
<vxml version="2.0" xmlns="http://www.w3.org/2001/vxml">
<!-- allow barge-in from dtmf -->
<property name="bargein" value="dtmf" />
<!-- dtmf only is recongized, not speech -->
<property name="inputmodes" value="dtmf" />
<var name="ANI" expr="'_XO_WIN_PHONE_'" />
<var name="DNIS" expr="0"/>
<!-- vars for names -->
<var name="fromname" expr="'_NAME1_'" />
<var name="toname" expr="'_NAME2_'" />
<!--
- Create handler to do post-call processing triggered by <disconnect>
- report back with call times and result via the subdialog tag
-->
<var name="timestart" expr="new Date()" />
<var name="timeend" expr="new Date()" />
<var name="timelen" expr="0" />
<var name="xferstart" expr="0" />
<var name="xferend" expr="0" />
<var name="xferresult" expr="'nocall'" />
<var name="xferduration" expr="0" />
<var name="bNotified" expr="0" />
<var name="errmsg" expr="'none'" />
<catch event="telephone.disconnect.hangup" >
<!-- The following conditional is a workaround to catch a near_end_disconnect during blocking transfer -->
<if cond="document.xferstart != 0">
<assign name="document.xferresult" expr="'near_end_disconnect'" />
<assign name="document.xferend" expr="new Date()" />
<assign name="document.xferduration" expr="document.xferend.getTime() - document.xferstart.getTime()" />
</if>
<goto next="#NotifyWIN" />
</catch>
<catch event="error" >
<assign name="document.errmsg" expr="_message" />
<goto next="#NotifyWIN" />
</catch>
<!-- Start of call -->
<form id="MainPrompt">
<!--
Only accept 1 or 2 - any other key will cause re-prompting.
-->
<field name="ConfirmMenu" type="boolean?y=1;n=2">
<prompt>
<emphasis>Hello.</emphasis>This is Zo-Go calling to connect you to
<prosody rate="default"><say-as type="name"> <value expr="document.toname" /> </say-as></prosody>.
<prosody rate="default">To connect, press 1. To disconnect, press 2.</prosody>
</prompt>
</field>
<noinput>
<audio>Are you there? </audio>
<reprompt/>
</noinput>
<noinput count="2">
<audio>I did not hear you.</audio>
<reprompt/>
</noinput>
<noinput count="3">
<goto next="#SaySorry" />
</noinput>
<nomatch>
<reprompt/>
</nomatch>
<nomatch count="3">
<goto next="#SayWhat" />
</nomatch>
<!--
Any response other than 1 or 2 will cause re-prompting. No answer or a busy signal
will not get here, so if 1, we try to connect the second call; if 2, we reject the attempt.
Note that we set the xferresult variable at document scope, otherwise it is local scope and lost.
-->
<filled>
<if cond="ConfirmMenu == '1'">
<goto next="#TryConnect" />
<else/>
<assign name="document.xferresult" expr="'rejected'" />
<goto next="#SayGoodbye" />
</if>
</filled>
</form>
<!-- Dial out to 2nd caller -->
<form id="TryConnect">
<block>
<audio> Connecting now. </audio>
<assign name="document.xferstart" expr="new Date()" />
</block>
<transfer name="T_1" dest="tel:+1_TO_';ani=_XO_WIN_PHONE_" bridge="true" cond="true" connecttimeout="60s" maxtime="_CALLDURATION_s" />
<filled>
<assign name="document.xferresult" expr="T_1" />
<assign name="document.xferduration" expr="T_1$.duration" />
<goto next="#SayGoodbye" />
</filled>
</form>
<!-- Say Goodbye to caller -->
<form id="SayGoodbye">
<block>
<audio> Thanks for using Zo-Go. Goodbye. </audio>
<goto next="#NotifyWIN" />
</block>
</form>
<!-- Cannot hear caller -->
<form id="SaySorry">
<block>
<audio> I did not hear any response. Please try again later. </audio>
<goto next="#SayGoodbye" />
</block>
</form>
<!-- Cannot understand caller -->
<form id="SayWhat">
<block>
<audio> I cannot understand you. Please try again later. </audio>
<goto next="#SayGoodbye" />
</block>
</form>
<!-- Call Post Processing: Notify WIN of results -->
<form id="NotifyWIN">
<!-- Contact WIN system with results -->
<block>
<assign name="document.timeend" expr="new Date()" />
<assign name="document.timelen" expr="document.timeend.getTime() - document.timestart.getTime()" />
<if cond="document.bNotified == 1">
<goto next="#Done" />
</if>
</block>
<var name="reqid" expr="_REQID_" />
<var name="from" expr="'_FROM_'" />
<var name="to" expr="'_TO_'" />
<subdialog src="_SVC_CALL_RESULTURL_" maxage="0" method="post" namelist="document.errmsg document.xferduration document.xferresult document.timelen from to reqid" />
<filled>
<assign name="document.bNotified" expr="1" />
<goto next="#Done" />
</filled>
</form>
<!-- End of script -->
<form id="Done">
<!-- end of script: do nothing -->
</form>
</vxml>

Note that before execution, capitalized variables that begin and end with an underscore are replaced on a call-by-call basis. While reviewing this post, I notice that indentation has been removed, for which I apologize.

We really do appreciate your taking the time to help us with this. I fully expect this to be something in our script, but I just can't see what.

Dorsey

[support]

I think I have it figured out. Your calculate transfer duration two different ways depending on whether a near-end disconnect occurs (upon which you execute IVR code within your first catch) or when a far-end disconnect occurs (upon which you execute the filled block of your <transfer> ). The calculation for the former is as follows:

Code: Select all

<assign name="document.xferduration" expr="document.xferend.getTime() - document.xferstart.getTime()"/>

whereas the calculation in the latter case is:

Code: Select all

<assign name="document.xferduration" expr="T_1$.duration"/>

The problem is, while the latter is an integer representing the number of seconds that elapsed during the transfer, the former is arithmetic on integers representing milliseconds.

So the correct calculation in the <catch> should be:

Code: Select all

<assign name="document.xferduration" expr="(document.xferend.getTime() - document.xferstart.getTime())/1000"/>

[dorsey]

Fantastic! Based on your suggestion, I've also modified the expression that returns the total call length (document.timelen) so that we now uniformly return seconds as the unit for returned values.

Thank you very much for your VXML assistance and for your quick response on this,
Dorsey