RE: clarification regarding processing of <mark>

Rethish,

>>is the mark information received before sending the BARGEIN_OCCURED to
be honoured or the last one is to be honoured?

The statement from the VoiceXML 2.1 specification "the mark last
executed by the SSML processor before barge-in occurred" is protocol and
implementation agnostic. To comply with the spec, your implementation
must use the mark that was executed closest to but no later than when
the actual bargein occurred as determined by the recognizer. In your
case, you will likely need to use timestamp information to choose the
correct mark and set the lastresult$ properties to the correct values.

Regards,

Matt Oshry
________________________________

From: www-voice-request@w3.org [mailto:www-voice-request@w3.org] On
Behalf Of rethish
Sent: Thursday, November 23, 2006 9:14 PM
To: www-voice@w3.org
Subject: clarification regarding processing of <mark>



 

Hi;

The <mark> element in VoiceXML 2.1 specifies that the "markname" in
application.lastresult$ is to be set as the "name of the mark last
executed by the SSML processor before barge-in occurred".

But there could be a cross-over scenario when the Speech synthesizer and
Speech Recognizer are not part of the same MRCP session.

In this case, the Speech recognizer would send a START-OF-INPUT on
bargein to the client which would send a BARGE-IN-OCCURED to the Speech
Synthesizer. 

But there could be a delay in sending the latter message and new <mark>
could have been executed by this time. 

 

So, is the mark information received before sending the BARGEIN_OCCURED
to be honoured or the last one is to be honoured?

 

Thanks & regards

Rethish

 

This e-mail and attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure,
reproduction, or dissemination) by persons other than the intended
recipient's) is prohibited. If you receive this e-mail in error, please
notify the sender by phone or email immediately and delete it

Received on Tuesday, 28 November 2006 22:32:18 UTC