<record> tag behaviour

Hi,

I wanted to understand the behaviour of the <record> tag in a particular 
situation we are facing in our application.

As per section 2.3.6.
<SNIP>
If no audio is collected during execution of <record>, then the record 
variable remains unfilled (note). This can occur, for example, when DTMF or 
speech input is received during prompt playback or before the timeout 
interval expires. In particular, if no audio is collected before the user 
terminates recording with DTMF input matching a local DTMF grammar (or when 
the dtmfterm attribute is set to true), then the record variable is not 
filled (so shadow variables are not set), and the FIA applies as normal 
without a noinput event being thrown. However, information about the input 
may be available in these situations via application.lastresult$ as 
described in Section 5.1.5.
<SNIP>

We have a record tag in our application (something similar to the one below)
<record name="msg" beep="true" maxtime="15s" finalsilence="1000ms" 
type="audio/wav">
  <prompt>
    Please record your message after the beep
  </prompt>

  <filled>
     <prompt>you said </prompt><value expr="msg"/>
  <filled>

  <noinput><reprompt/></noinput>
</record>

When the user calls in the prompt plays, if the user says nothing for a 
couple of secs and presses the pound key, as per the spec, msg is not filled 
and neither a noinput event is not thrown. The prompt plays again and the 
user can do the same thing again and again.
And this can continue repeatedly with no end.

My question is whether this design was intentional? And if so what were the 
driving factors ?
And would it be possible down the line to have something in place to prevent 
this scenario.
Say either throw a noinput or have a maxattempts attribute in tag. Which 
will try to
record only so many times.

Thank you very much.

:)
Sulakshan

_________________________________________________________________
On the road to retirement? Check out MSN Life Events for advice on how to 
get there! http://lifeevents.msn.com/category.aspx?cid=Retirement

Received on Saturday, 18 March 2006 13:39:09 UTC