[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On May 6, 2009, at 3:26 AM, Slawomir Testowy wrote:


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.


Thanks.





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?


Yes.



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

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. 





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





C->S:  MRCP/2.0 289 SPEAK 543259
      Channel-Identifier:32AECB23433801 at 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 at speechsynth
       Speech-Marker:timestamp=857207696314


[...]


C->S:  MRCP/2.0 69 BARGE-IN-OCCURRED 543259
       Channel-Identifier:32AECB23433801 at speechsynth
        Proxy-Sync-Id:987654321

 S->C:  MRCP/2.0 72 543259 200 COMPLETE
       Channel-Identifier:32AECB23433801 at speechsynth
        Active-Request-Id-List:543258
        Speech-Marker:timestamp=857206096314

 S->C:  MRCP/2.0 73 SPEAK-COMPLETE 543259 COMPLETE
       Channel-Identifier:32AECB23433801 at 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?


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




--
Slawomir Testowy
_______________________________________________
Speechsc mailing list
Speechsc at ietf.org
https://www.ietf.org/mailman/listinfo/speechsc
Supplemental web site:
<http://www.standardstrack.com/ietf/speechsc>