W3C home > Mailing lists > Public > www-voice@w3.org > January to March 2006

RE: <record> tag behaviour

From: Pandey, Arvind (Arvind)** CTR ** <pandeya@lucent.com>
Date: Mon, 20 Mar 2006 10:28:49 +0530
Message-ID: <3BE48DD0EC7D3948BC183931D9150C21040444C0@ii0015exch001u.iprc.lucent.com>
To: "'Sulakshan Shetty'" <sulakshan@hotmail.com>, www-voice@w3.org


You can use <noinput count=1> or <nomatch count=1> and strict the
application. as soon as the count increases to the specified counter u can
check that and transfer control according to your requirement.


-----Original Message-----
From: www-voice-request@w3.org [mailto:www-voice-request@w3.org]On
Behalf Of Sulakshan Shetty
Sent: Saturday, March 18, 2006 7:09 PM
To: www-voice@w3.org
Subject: <record> tag behaviour


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.
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.

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

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


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.


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 Monday, 20 March 2006 04:59:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:38 UTC