Re: [Speechsc] Ambiguous description of BARGE-IN-OCCURRED in section 8.8

[Slawomir Testowy <slawomir.testowy at gmail.com>]

2009/5/6 Dan Burnett <dburnett at voxeo.com>:

Hi, thanks for your answers. They helped me understand how a server
should respond
on BARGE-IN-OCCURRED.

>>
>> I couldn't find a definition of "active SPEAK request". I guess it is
>> a current processed "SPEAK"?
>
> I agree that the current use of the word "active" is a bit confusing.  It is
> clearer if you understand the point of the BARGE-IN-OCCURRED event.  When an
> ASR engine detects speech, if a prompt (audio) is being played the client
> usually wants to cancel the audio being played.  The kill-on-barge-in
> parameter and BARGE-IN-OCCURRED event allow for this.  Since the audio is
> interrupted (but did not stop due to a failure in the synthesis resource),
> it has a normal termination, meaning that there is a SPEAK-COMPLETE
> generated for this bit of audio.  Anything queued up after it (PENDING),
> however, is removed from the queue since the occurrence of speech during a
> prompt usually will cause a change in the dialog direction that can
> invalidate all queued prompts.  The reason no SPEAK-COMPLETE is sent for
> these removed PENDING requests is to distinguish them from the case where a
> failure occurs during the playout of the current audio.  In that case (see
> Section 8.6, next-to-last paragraph), each PENDING request stops with a
> SPEAK-COMPLETE (with Completion-Cause of "cancelled").
>

I don't see this paragraph in RFC4463. Was it introduced in MRCPv2?
Maybe this is a little bit offtopic, but how should server implementing MRCPv1
behave in such case?

> So, in the text above "active" means either IN-PROGRESS or PAUSED.
>
>>
>>
>>> It MUST also terminate any speech requests
>>> queued behind the current active one, irrespective of whether they
>>> have barge-in enabled or not.
>>
>> Does this statement depend on previous one? I.e. must the synthesizer
>> terminate all speech
>> requests queued behind the current one regardless of kill-on-barge-in
>> enabled in active "SPEAK"?
>
> It depends on the previous statement.  If kill-on-barge-in is enabled for
> the currently active SPEAK request, then all queued (PENDING) requests are
> terminated regardless of whether or not they have kill-on-barge-in enabled.
>

Just to be sure: If kill-on-barge-in is disabled for the currently
active SPEAK request,
server returns SUCCESS without an active-request-id-list header as
described in next-to-last
paragraph in 8.8?

-- 
Slawomir Testowy