Missed Key Presses on Replay App

[tloring]

tloring: There is one issue I am noticing: intermittently when I press a key (this will happen on consecutive button presses as well), I am getting the audio replay, but the "pressed" field apparently is not getting filled (i'm not getting the spoken elapsed time and button press). It must be falling through to the catchall, but I'm not sure why. I thought maybe the interdigittimeout was a problem at 0, so I tweaked that around a bit; I also tweaked the timeout on the catchall. No avail.

support: Here is a slightly modified version. The difference is in how precise the timing are calculated, and it is possible to "sneak" a digit despite a 10ms interdigittimeout. You will have to enable one of our newer features that forces grammars that specify a length to terminate once that length has been reached. So in this case with a type of digits?length=1, the system will stop listening for dtmf input after the first digit without exception. This feature is off by default because it breaks previous systems that request a # termination while still setting digits?length=n.

Code: Select all

<?xml version='1.0'?>
<vxml version="2.0">

<var name="startTime"/>
<var name="endTime"/>
<var name="elapsedTime"/>

<form id="replay">
  <property name="interdigittimeout" value="10ms"/>
  <property name="termmaxdigits" value="true"/>

  <block>
    <audio src="http://banfield/~mjones/qa/plumvp/prompts/audio/internet.wav"/>
    <assign name="startTime" expr="(new Date()).getTime()"/>
  </block>

  <field name='pressed' type="digits?length=1">
    <filled>
      <assign name="endTime" expr="(new Date()).getTime()"/>
      <assign name="elapsedTime" expr="Math.round((endTime - startTime)/1000)"/>
      at <value expr="elapsedTime"/> seconds
      <if cond="pressed==4">Jump Back
      <elseif cond="pressed==6"/>Jump Ahead
      <elseif cond="pressed==8"/>Insert
      <elseif cond="pressed==0"/>Menu
      <else/>No Action
      </if>
      <goto nextitem="catchall"/>
    </filled>
    <catch event="nomatch noinput">
      <goto next="#replay"/>
    </catch>
  </field>
 
  <!-- this catchall prevents queuing of #replay -->
  <property name="timeout" value="10ms"/>
  <field name="catchall" type="digits">
    <filled>
      <goto next="#replay"/>
    </filled>
    <catch event="nomatch noinput">
      <goto next="#replay"/>
    </catch>
  </field>
</form>
</vxml>

tloring: I've tested this, and am having the same problem, no difference.

I copy/pasted the code below and changed only the audio src file. The problem actually seems more prevalent now - in 24 calls the problem manifested itself consistently every call w/i 3 button presses, many times on the first; previously it seemed less consistent. On my audio, I'm waiting about 3 seconds each time before I press.

Is the new feature on the murrow machine (or whichever is serving the 617.712.3548 number)? This no doubt worked fine on an internal support machine, but does not seem to have an effect on the production machine.


Thanks,
Thom

[support]

Hi Tom:

Apologies are in order for the lack of prompt response. We have been working on your problem; your posts have not gone unnoticed. We should have an answer to this IVR issue by the end of the working day (Tuesday, August 24th).

kind regards,

Plum Support

[support]

Hi Tom:

Been workin on an improved version:

Code: Select all

<?xml version='1.0'?>
<vxml version="2.0">

<var name="startTime"/>
<var name="endTime"/>
<var name="elapsedTime"/>
<var name="processingTime" expr="0"/>

<form id="replay">
  <property name="interdigittimeout" value="10ms"/>
  <property name="inputmodes" value="dtmf"/>
  
  <block>
    <audio src="http://banfield/~mjones/qa/plumvp/prompts/audio/internet.wav"/>

    <assign name="startTime" expr="(new Date()).getTime()"/>
  </block>

  <field name='pressed' type="digits?length=1">
    <filled>
      <assign name="endTime" expr="(new Date()).getTime()"/>
      <assign name="elapsedTime" expr="Math.round((endTime - startTime - processingTime)/1000)"/>
      <prompt bargein="false">
        at <value expr="elapsedTime"/> seconds
      </prompt>

      <if cond="pressed==4">
        <prompt bargein="false">Jump Back</prompt>
      <elseif cond="pressed==6"/>
        <prompt bargein="false">Jump Ahead</prompt>
      <elseif cond="pressed==8"/>
        <prompt bargein="false">Insert</prompt>
      <elseif cond="pressed==0"/>

        <prompt bargein="false">Menu</prompt>
      <else/>
        <prompt bargein="false">No Action</prompt>
      </if>

      <assign name="processingTime" expr="(new Date()).getTime()-endTime"/>
      <goto next="#replay"/>
    </filled>

    <catch event="nomatch noinput">
      <goto next="#replay"/>
    </catch>
  </field>
 
</form>
</vxml>

Again, this will not get around the IVR issue caused by fetch latency, but it will work otherwise.

hope this is of some help,

Plum Support

[tloring]

This does seem to address the issue...I'm not sure I understand why/how exactly...I have a few questions.

On my first look, the solution looked to be primarily <prompt bargin="false"> tags around the text for each of the conditional contents w/ the "pressed" field. Those prompts are just there for test feedback, that will actually be code to do some calcs on positioning which will be then passed to via the <audio> expr to return the right audio segment. On further review, that just seemed to be the most obvious difference - perhaps for doing the test prompts themselves this is necessary? - I kind of recall bargein defaulting to true, but since I'm using dtmf only this shouldn't really be an issue, should it?

Also, the fetch latency handling, which worked in the previous incarnation, is essential. I'm not sure why the solution to this issue would require its removal, unless this was simply to focus on this particular issue. On further review, it looks as though this is being compensated for with the "processingTime" variable. Is this correct? It seems to work. In fact this seems like a cleaner implementation. I'm confused because you state "this will not get around the issue caused by fetch latency". Could you please clarify?

I am getting some issues on the calculations, ie -0, -1 seconds, there seems to be some slight inconsistancy there, but that may be attributable to rounding and reaction time, I'm not sure yet. I will need to test further.

I have been building out the functionality here using the previous solution on a different platform, I'll incorporate this solution and test it with that as well.

Thanks,
Thom

[support]

In order to properly explain why those prompts need to be bargein="false" we should first explain the situation of bargein="true". So, if those prompts inside the <filled> block were set to true, here is the order of execution in the IVR system.

The initial processing happens as expected:
1. The primary audio file is fetched.
2. startTime is assigned.
3. Playback begins.

This section begins the loop:
4. Upon user input the IVR system performs a grammar check and starts executing the filled block.
5. endTime and elapsedTime are assigned.
6. The if/elseif/else sections are evaluated and audio is generated from the text output. This audio is pushed into the queue.
7. processingTime is assigned.
8. The primary audio file is fetched.
9. startTime is assigned
10. Playback begins.
11. Go back to #4


However, if the <filled> block contains non-bargeable prompts the behavior changes as follows.
This version loops back to the beginning:
1. The primary audio file is fetched.
2. startTime is assigned.
3. Playback begins.
4. Upon user input the IVR system performs a grammar check and starts executing the filled block.
5. endTime and elapsedTime are assigned.
6. The if/elseif/else sections are evaluated and audio is generated from the text output. This audio is pushed into the queue.
7. processingTime is assigned.
8. Playback begins.
9. Playback ends.
10. Go back to #1


Given these two behaviors, it can be determined that the primary cause of the timing problems is actually related to the fact that you have a "feedback loop" stating what was pressed at all. If you were to take that out, it is very likely that there would be no need to worry about bargein, or having a processingTime variable. Also to clarify, the processingTime variable attempts to compensate for the amount of time required to generate the audio from the TTS.

To answer your other question regarding the statement:

this will not get around the issue caused by fetch latency

This statement alludes to the fact that dtmf input pressed while audio is being fetched is completely discarded. This is intentional and is designed to avoid collecting input when the user is pressing dtmf because the IVR system doesn't appear to be responding (silence during a fetch).

Hope this helps clarify the logic behind the previous script.

The Plum Support Team

[tloring]

Thanks for the clarification!

So, really this test case produced a red herring since I used prompts to indicate the action, prompts being the equivalent to quick and dirty printf's. Though, I was further thrown off in that this behaviour did not occur via another platform.

And you were refering to the fetch latency of the original audio to be played back - I misinterpreted that as the original timing issue.

On the matter of diagnostics...

In retrospect, had I emitted messages w/ <log>, I'd have avoided this whole issue. I have a log on the server side, but obviously messages are only generated when vxml documents are retrieved/posted, in this case I needed feedback/messages while this is processing w/i a document on the plum side.

I know I have access to the session log via the web interface, and I've got a CLI to access that more conveniently for myself. Ideally, I'd like to be able to 'tail -f' that session log, is there a way to do that? Ie, behind the scenes, is there an account w/ log files which I could do an 'ssh host tail -f sessionlog'?

I have come across another vendor which has a custom tag which does some provide for logging to a server w/i a processing document; I don't recall who actually, but it was a <send> tag or something. Is there by chance a similar mechanism on plum?

Or, is there a way to implement that type of functionality? I seem to recall seeing something is this regard, I believe in a discussion on subdialogs, that at least led me to believe this could be implemented. I need to dig around, but if you by chance have an example of something like this...well, would love to see it.

Thanks,
Thom

[support]

Currently there is no way to do a running tail on our IVR session logs (on the hosted IVR site). However, this is a feature that is being considered for the hosted IVR site in the future. It would likely work in a similar manner to the live IVR logs, except that it would be for the DNIS session logs.

It is possible that the functionality you are looking for could be achieved in some other way. It is fairly easy to use a <subdialog> to perform a <submit> that could write to a file on your side of things. Given that you could obviously maintain a tail -f on your side of things.

If you could provide an example of what exactly you are trying to do, I'm sure we could provide you with some simple VoiceXML code to perform that task.

Hope this helps.
The Plum Support Team