User Input buffer

[millsey]

When using User Input, if we have a prompt with Allow Barge set to FALSE, any digits pressed during the prompt are stored and input as soon as the prompt finishes. Is there a way to clear the buffer as soon as the prompt finishes playing?

Thanks

Brian

 

[VAD_Support]

Hi Brian,

Not 100% sure, but something you could try is playing your non-interruptable prompt using a Prompt Playback component, and then continue with a User Input component. That way the prompt will be played outside the "field" element of the generated voicexml, and then as per the VoiceXML recommendation, the buffer should be cleared.

Please, give it a try and let me know.

The other option that comes to my mind would be manually changing the generated voicexml script, but that will be more difficult, and also you would have to do it after each build...

Regards,

 

[millsey]

I was wondering why this was nto working and came back to this discussion.

I have a userinput to ask if the caller knows their number, then press 1, I then have prompt playback followed by a second input ( if user has pressed one).

The input buffer is not cleared when the system progresses from the prompt playback to the user input. So if the user starts pressing buttons during the prompt, those buttons are added to the input.

Clearly this is a fault, I am looking for a workaround which does nto involve splitting the whole flow down into lots of little components.

Millsey

 

[millsey]

BUMP

Any way to clear the buffer? Even if I have to modify the XML files to add an instruction I will do this as we have a lot of people who start dialling early whilst the spoken instructions are being read out. Is there any hacky way to fix this e.g. put another component inbetween the prompt playback and the digit clollection?

Brian

 

[VAD_Support]

Hi Brian,

Try changing the prompt elements by adding the bargein attribute and setting it to false. For example, instead of:
<prompt count="1">

use this:
<prompt bargein="false" count="1">

As far as I know, the prompt should take the value from the bargein property, so maybe this change doesn't affect the behavior, but you could give it a try.

This is the Voice XML recommendation, you may find useful information there:
http://www.w3.org/TR/voicexml20/

 

[millsey]

Thanks, will try that tomorrow.

Millsey

 

[millsey]

Actually that causes the flow to fail.


<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.0" application="Root_SelfServe2.vxml">
<catch event="error.semantic">
<assign name="project$_CurrentErrorName$" expr="_event" />
<assign name="project$_CurrentErrorDescription$" expr="(_message == undefined ? '' : _message)" />
<goto next="SelfServe2_ErrorHandler.vxml" />
</catch>
<error>
<assign name="project$_CurrentErrorName$" expr="_event" />
<goto next="SelfServe2_ErrorHandler.vxml" />
</error>
<catch event="connection.disconnect telephone.disconnect">
<goto next="SelfServe2_DisconnectHandler.vxml" />
</catch>
<var name="application.SelfServe2_inputref_Result" expr="''" />
<var name="application.SelfServe2_inputref_Buffer" expr="''" />
<form id="userinput">
<property name="bargein" value="false" />
<property name="timeout" value="5s" />
<property name="interdigittimeout" value="5s" />
<property name="termtimeout" value="5s" />
<property name="termchar" value="#" />
<field name="userinput">
<grammar>[0|1|2|3|4|5|6|7|8|9|*]{7-13}</grammar>
<prompt count="2">
<audio src="file:///C:\ProgramData\3CX\Data\Http\Interface\ivr\SelfServe2_13\cant_find_ref_2.wav" />
<audio src="file:///C:\ProgramData\3CX\Data\Http\Interface\ivr\SelfServe2_13\dial_in_ref_2.wav" />
</prompt>
<catch event="nomatch noinput" count="3">
<assign name="SelfServe2_inputref_Result" expr="(_event == 'noinput' ? UserInputResult_Timeout : UserInputResult_InvalidDigits)" />
<assign name="SelfServe2_inputref_Buffer" expr="(application.lastresult$ == undefined ? '' : application.lastresult$.utterance)" />
<goto next="SelfServe2_MF_inputref_Invalid_Input.vxml" />
</catch>
<nomatch count="1">
<prompt>
<audio src="file:///C:\ProgramData\3CX\Data\Http\Interface\ivr\SelfServe2_13\ref_number_not_found-010912.wav" />
</prompt>
<reprompt />
</nomatch>
<filled>
<assign name="SelfServe2_inputref_Result" expr="UserInputResult_ValidDigits" />
<assign name="SelfServe2_inputref_Buffer" expr="(application.lastresult$ == undefined ? '' : application.lastresult$.utterance)" />
<goto next="SelfServe2_MF_inputref_Valid_Input.vxml" />
</filled>
</field>
</form>
</vxml>


Changing the <prompt count="2"> to <prompt bargein="false" count="2"> causes the input to repeat then cut the caller off.

I can see the variables for the buffer being set to blank, but the resultant output of this component contains anything dialled during the immediately previous prompt (which has bargein set to false) plus anything dialled during this input collection.

The imediately previous prompt is:

<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.0" application="Root_SelfServe2.vxml">
<catch event="error.semantic">
<assign name="project$_CurrentErrorName$" expr="_event" />
<assign name="project$_CurrentErrorDescription$" expr="(_message == undefined ? '' : _message)" />
<goto next="SelfServe2_ErrorHandler.vxml" />
</catch>
<error>
<assign name="project$_CurrentErrorName$" expr="_event" />
<goto next="SelfServe2_ErrorHandler.vxml" />
</error>
<catch event="connection.disconnect telephone.disconnect">
<goto next="SelfServe2_DisconnectHandler.vxml" />
</catch>
<form id="play">
<block>
<prompt bargein="false">
<audio src="file:///C:\ProgramData\3CX\Data\Http\Interface\ivr\SelfServe2_13\dial_in_ref_2.wav" />
</prompt>
<goto next="SelfServe2_MF_inputref.vxml" />
</block>
</form>
</vxml>

 

[VAD_Support]

So, if I understood it well, the problem are the digits entered during the previous prompt and not during the user input execution, right?

Something to try could be adding a <clear/> element between the prompt and the goto elements, so variables used into the form are cleared. I'm not sure if the buffer counts as a variable or not, but it's something to try. This is how the previous file should be:

<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.0" application="Root_SelfServe2.vxml">
<catch event="error.semantic">
<assign name="project$_CurrentErrorName$" expr="_event" />
<assign name="project$_CurrentErrorDescription$" expr="(_message == undefined ? '' : _message)" />
<goto next="SelfServe2_ErrorHandler.vxml" />
</catch>
<error>
<assign name="project$_CurrentErrorName$" expr="_event" />
<goto next="SelfServe2_ErrorHandler.vxml" />
</error>
<catch event="connection.disconnect telephone.disconnect">
<goto next="SelfServe2_DisconnectHandler.vxml" />
</catch>
<form id="play">
<block>
<prompt bargein="false">
<audio src="file:///C:\ProgramData\3CX\Data\Http\Interface\ivr\SelfServe2_13\dial_in_ref_2.wav" />
</prompt>
<clear/>
<goto next="SelfServe2_MF_inputref.vxml" />
</block>
</form>
</vxml>

The Voice XML specification states that if the prompt is configured with bargein="false" then the buffer should be automatically cleared after it transitions to the next document, and that is not happening, so maybe this is a bug in the implementation...

Please, give it a try and let me know.

Regards,

 

[millsey]

So, if I understood it well, the problem are the digits entered during the previous prompt and not during the user input execution, right?

-- Sort of. ALL digits dialled during but the previous prompt and the user input are collected together.

The addition of the <clear/> in the position you showed me did not work, it made no difference.

Millsey

 

[VAD_Support]

Well, it seems to be a problem in the underlying VoiceXML interpreter.

Is there a good reason why you need to avoid the bargin? Users usually learn to use the IVR and want to go quickly to the part they want, so they enter DTMF digits before the prompt is completed. If you really need to do this, then the only solution I can imagine is splitting the callflow in parts, and transfer the call from one callflow to another. This way each part is a different call, and then 100% sure the buffer will be cleared. But if you do this, you need to store the state that you need to persist into a database or something like that, because variables are reset between calls.

 

[millsey]

The reference number we are asking for is of the format 123456m3 and 123456FUN3 and 123456w1 and some F123456789 so we have to tell the caller to dial a star for any letters then press hash to finish. Otherwise we get all sorts of freestyle dialling which would prevent us from looking up the reference in a database.

Our announce is "PDial in your reference number replacing any letters with a star, then press hash"

What we get is people starting to dial, then they redial the digits from the start so instead of 123456*3 we get 123123456*3

The obvious fix is to clear the buffer as soon as we are listening.

THe only thing I can think of is because we haev a prompt before the user input, we don't have an initial prompt within the user input, could that make a difference?

 

[VAD_Support]

An initial prompt could make the difference, because the generated VoiceXML puts all the prompts into the same form. Please try changing that and let me know.

Anyway, for experienced users, it could be a bit annoying to be forced to wait until the prompt ends, if they already know the format to use...

 

[millsey]

I have added an initial prompt (a beep) and it did not fix the issue. I haev found another problem also, and will open a seperate thread for that one.

 

[millsey]

If I split the flow up, should I use components within a single flow or should I transfer to another flow?

Im thinking that if I play the advice in a flow then transfer to another flow, it will have a clear buffer, but will it be quick enough to be seamless for the user? I dont want it to delay receiving the digits or for the caller to hear momentary Music..

 

[VAD_Support]

You need to transfer the call between 2 callflows. A user component called from the same callflow will not be executed in another call, so the problem will persist. The transfer should be quick, the call is answered automatically, so the user should not hear much music on hold. Anyway, you can make a quick test to be sure before making all the changes.