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

From: Slawomir Testowy <[email-masked]>
Date: Wed, 6 May 2009 09:26:32 +0200

Hi,

I am reading draft-18 and I find description of BARGE-IN-0CCURRED
method hard to understand.

> 8.8.  BARGE-IN-OCCURED

There is a typo.

> If a "SPEAK" request is active with kill-on-barge-in enabled, and the
> BARGE-IN-OCCURRED event is received, the synthesizer MUST immediately
> stop streaming out audio.

Must the synthesizer stop streaming out audio if a "SPEAK" request is
in "PAUSED" state?
I couldn't find a definition of "active SPEAK request". I guess it is
a current processed "SPEAK"?

> 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"?

> If a barge-in-able "SPEAK" request was
> playing and it was terminated, the response MUST contain the an
> active-request-list header listing the request-ids of all "SPEAK"
> requests that were terminated.  The server generates no
> "SPEAK-COMPLETE" events for these requests.

That sounds good. However, example in section 14.1 says something different:

>  C->S:  MRCP/2.0 289 SPEAK 543259
>        Channel-Identifier:32AECB23433801@speechsynth
>        Kill-On-Barge-In:true
>        Content-Type:application/ssml+xml
>        Content-Length:418
>        Content-Length:...

[...]

>   S->C:  MRCP/2.0 52 543259 200 IN-PROGRESS
>         Channel-Identifier:32AECB23433801@speechsynth
>         Speech-Marker:timestamp=857207696314

[...]

> C->S:  MRCP/2.0 69 BARGE-IN-OCCURRED 543259
>         Channel-Identifier:32AECB23433801@speechsynth
>          Proxy-Sync-Id:987654321
>
>   S->C:  MRCP/2.0 72 543259 200 COMPLETE
>         Channel-Identifier:32AECB23433801@speechsynth
>          Active-Request-Id-List:543258
>          Speech-Marker:timestamp=857206096314
>
>   S->C:  MRCP/2.0 73 SPEAK-COMPLETE 543259 COMPLETE
>         Channel-Identifier:32AECB23433801@speechsynth
>         Completion-Cause:001 barge-in
>         Speech-Marker:timestamp=857207685213

Moreover, request BARGE-IN-OCCURRED has the same request-id
as previous SPEAK. Is this correct?

--
Slawomir Testowy

---

From: Dan Burnett <[email-masked]>
Date: Wed, 6 May 2009 13:29:02 -0400

> method hard to understand.

Thanks.

> Must the synthesizer stop streaming out audio if a "SPEAK" request is

Yes.

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

So, in the text above "active" means either IN-PROGRESS or PAUSED.

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

> That sounds good. However, example in section 14.1 says something  

Yes, the wording above is unclear.  The server generates a SPEAK- 
COMPLETE event for the barged-in SPEAK request with a completion-cause  
of "barge-in" so the client knows that the audio was stopped, and for  
that reason.  However, no SPEAK-COMPLETE messages are sent for the  
queued messages that were terminated because of the barge-in.

> as previous SPEAK. Is this correct?

Oops, no, that's a typo.  It should have a different request-id.

>
>
> --
> Slawomir Testowy
> _______________________________________________
> Speechsc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/speechsc
> Supplemental web site:
> &lt;http://www.standardstrack.com/ietf/speechsc&gt;

---

From: Slawomir Testowy <[email-masked]>
Date: Fri, 8 May 2009 13:00:52 +0200

2009/5/6 Dan Burnett <[email-masked]>:

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

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

> 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