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

Slawomir Testowy <slawomir.testowy@gmail.com> Fri, 08 May 2009 10:59 UTC

Return-Path: <slawomir.testowy@gmail.com>
X-Original-To: speechsc@core3.amsl.com
Delivered-To: speechsc@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1504E3A6F95 for <speechsc@core3.amsl.com>; Fri, 8 May 2009 03:59:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.542
X-Spam-Level:
X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWReXpom5cGw for <speechsc@core3.amsl.com>; Fri, 8 May 2009 03:59:28 -0700 (PDT)
Received: from mail-bw0-f174.google.com (mail-bw0-f174.google.com [209.85.218.174]) by core3.amsl.com (Postfix) with ESMTP id E6C4A3A6D82 for <speechsc@ietf.org>; Fri, 8 May 2009 03:59:27 -0700 (PDT)
Received: by bwz22 with SMTP id 22so1300635bwz.37 for <speechsc@ietf.org>; Fri, 08 May 2009 04:00:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BBdu/euH4DTToWc7Ce9n9IXOVTA6nXh6S6XB/zxuQuQ=; b=DzFCBldOkPZ06gulf0fgIzGnNGqQ76ShicwvfbH9MFIdcIjkR9wULXfxlZ3NRFPIcw eEAiZv56aKhGt06+pwG2nncTk0ie2Dec03fMXab4r7UrePGD90kgnFhbebdMTSnmyOwj i1wa3fU0YcGEClShZ3e3bxvmTbCYkc38nv48A=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=iUAPaxTDLVGJuOJIzk931CK9VBZ3pK3jskz+e0rWvvBSn6fB0i86MdrKJfutx0Bnex aa7DDNvdjkCOszXC4bj6EtKMEfW2WsjnXrqSzDnSotF2yiWZexq2SJHf9NsnQijt3Fsv 6d/xaagvRSFVcMuyzqciXZhQUlW1NMmbXXUSQ=
MIME-Version: 1.0
Received: by 10.204.65.78 with SMTP id h14mr3518138bki.35.1241780452861; Fri, 08 May 2009 04:00:52 -0700 (PDT)
In-Reply-To: <62166606-B738-41CC-A7A0-58F681EFA6DA@voxeo.com>
References: <8681d1580905060026l3763d4e1g40f42e8299af59aa@mail.gmail.com> <62166606-B738-41CC-A7A0-58F681EFA6DA@voxeo.com>
Date: Fri, 08 May 2009 13:00:52 +0200
Message-ID: <8681d1580905080400o46a25499hfd61914858e4ec21@mail.gmail.com>
From: Slawomir Testowy <slawomir.testowy@gmail.com>
To: Dan Burnett <dburnett@voxeo.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: speechsc@ietf.org
Subject: Re: [Speechsc] Ambiguous description of BARGE-IN-OCCURRED in section 8.8
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Speech Services Control Working Group <speechsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/speechsc>, <mailto:speechsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/speechsc>
List-Post: <mailto:speechsc@ietf.org>
List-Help: <mailto:speechsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/speechsc>, <mailto:speechsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 May 2009 10:59:29 -0000

2009/5/6 Dan Burnett <dburnett@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