From speechsc-bounces@ietf.org Mon Aug 01 15:50:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzgJM-0004Gr-Ly; Mon, 01 Aug 2005 15:50:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzgIZ-0003uc-AD; Mon, 01 Aug 2005 15:50:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05118; Mon, 1 Aug 2005 15:50:04 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzgop-0001kU-Mh; Mon, 01 Aug 2005 16:23:29 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DzgIT-0004aW-Mh; Mon, 01 Aug 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 01 Aug 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: speechsc@ietf.org Subject: [Speechsc] I-D ACTION:draft-ietf-speechsc-mrcpv2-07.txt X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Speech Services Control Working Group of the IETF. Title : Media Resource Control Protocol Version 2 (MRCPv2) Author(s) : D. Burnett, S. Shanmugham Filename : draft-ietf-speechsc-mrcpv2-07.txt Pages : 198 Date : 2005-8-1 The MRCPv2 protocol allows client hosts to control media service resources such as speech synthesizers, recognizers, verifiers and identifiers residing in servers on the network. MRCPv2 is not a "stand-alone" protocol - it relies on a session management protocol such as the Session Initiation Protocol (SIP) to establish the MRCPv2 control session between the client and the server, and for rendezvous and capability discovery. It also depends on SIP and SDP to establish the media sessions and associated parameters between the media source or sink and the media server. Once this is done, the MRCPv2 protocol exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speechsc-mrcpv2-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-speechsc-mrcpv2-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-speechsc-mrcpv2-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-1134227.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speechsc-mrcpv2-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speechsc-mrcpv2-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-1134227.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --NextPart-- From speechsc-bounces@ietf.org Thu Aug 04 13:43:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0jkt-0001HH-T3; Thu, 04 Aug 2005 13:43:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0jks-0001H8-Sl for speechsc@megatron.ietf.org; Thu, 04 Aug 2005 13:43:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26588 for ; Thu, 4 Aug 2005 13:43:39 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0kHn-0002Vo-5i for Speechsc@ietf.org; Thu, 04 Aug 2005 14:17:44 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 04 Aug 2005 10:43:32 -0700 Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j74HhTZ1009447; Thu, 4 Aug 2005 10:43:29 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Server capabilities Date: Thu, 4 Aug 2005 10:43:28 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C2C34CA@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] Server capabilities Thread-Index: AcVx39fxai1AEoKoQPGwvIUpcV87iQAAwfggCc2qOnA= From: "Shanmugham, Saravanan" To: "Shanmugham, Saravanan" , "Corby Anderson" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Here is a suggestion to address this issue. The ability to discover the capabilities of an MRCP server is substantial piece of work in my opnion. Something that need a draft of its own. Its not a priority issue that should stop the MRCPv2 draft from progressing. I would suggest that we defer this work to a separate draft and allow us to finish this one. The current draft is pretty huge by itself. I like the idea of using SIP OPTIONS along with necessary SDP definitions that describe the capabilities of resources it supports. These I believe can be defered to a separate draft without affecting MRCPv2 very much.=20 This draft should also define mime-bodies that cover support for certain headers and their possible values(like CONTROL method and the different values supported for JumpSize etc).=20 It should also return a mime-body listing the grammars that are provisioned permanently on the server. What we not should do. I don't believe the installation of grammars that may be persistent across sessions should be the job of MRCPv2. I believe this should be a provisioning issue and addressed through SNMP or some other approach that may be used to install the server, the different resources/languages it supports etc. Sarvi =20 -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of=20 Shanmugham, Saravanan Sent: Wednesday, June 15, 2005 12:49 PM To: Corby Anderson; Speechsc@ietf.org Subject: RE: [Speechsc] Server capabilities =20 This comment is only relating to your suggestion to use=20 option b to address resolving binary grammar uri. I think the right way to do this would be to define a file=20 format for this binary across vendors and use it. This=20 wouldn't have to be very complex, at a minimum agree on=20 standard header for the beginning of this file that=20 identifies vendor and format version number and the rest=20 of the binary file could be vendor specific.=20 =20 No need to address this through the MRCP specification. =20 Sarvi=20 =20 -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Corby Anderson Sent: Wednesday, June 15, 2005 12:20 PM To: Speechsc@ietf.org Subject: Re: [Speechsc] Server capabilities =20 I'm very much in favor of b). =20 In the "managing big grammars" thread we were considering=20 about permitting URIs to reference binary grammars as well=20 as source grammars (was that ever codified?). How about=20 having some way for the server to indicate what=20 vendor/version it is. For heterogenous MRCP server=20 environments, this would allow clients to give the right=20 grammar binary URIs to the right servers. =20 Corby Anderson Tellme Networks, Inc. =20 David R. Oran wrote: =20 > This message was prompted by one aspect of the=20 discussion on the list=20 > about large grammars, which is how a client can figure=20 out in advance=20 > just what a server can and can't do, so it isn't=20 "unpleasantly=20 > surprised" at the instant it issues a method. > > The current specification walks a fine line between=20 giving flexibility=20 > to server implementers and giving clients a=20 sufficient degree of=20 > control over server behavior. For example we have things=20 like multiple=20 > jump-length units which a server may or may not support,=20 > server-specific default values for confidence-threshold and=20 > speed-vs-accuracy, and a bunch of others. > > There is some for this support, including: > 1) through SDP and SIP OPTIONS the client can discover=20 what resources=20 > the server supports and what media formats it can process. > 2) through GET-PARAMS on a particular session with a=20 resource the=20 > client can discover any implementation-specific server=20 default values=20 > for MRCPv2 protocol headers. > > My question to the WG is what, if anything do we need=20 beyond these? > > Here's a small list of candidates. Feel free to comment=20 and/or propose=20 > your own: > > a) we may want/need a way for the server to=20 determine what audio=20 > formats a client supports for the purposes of=20 returning captured=20 > audio. Right now we don't even have a way for the client=20 to tell the=20 > server what format it wants audio returned in, so we at=20 least have to=20 > remedy that omission. > > b) we may want a way for a client to learn the=20 current list of=20 > "instantly available" grammars the server has handy and=20 which are in=20 > some way "guaranteed" to persist for a while. > > c) we may want a form of GET-PARAMS which fetches=20 session-independent=20 > server information. One way to do this is to define a=20 MRCPv2-frag=20 > content type (like we have with sipfrag). That way a SIP=20 OPTIONs to an=20 > MRCPv2 server can return an MRCP-specific body with=20 all that=20 > interesting information about server capabilities. > > > I don't want this to necessary turn into a free-for-all,=20 because we=20 > really do want to reach closure on the spec and get it=20 to last call. > My target for finishing my chair review and editing is=20 the end of this=20 > week. > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Mon Aug 08 14:34:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2CSC-0005V3-GB; Mon, 08 Aug 2005 14:34:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2CSA-0005Uh-Px for speechsc@megatron.ietf.org; Mon, 08 Aug 2005 14:34:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07967 for ; Mon, 8 Aug 2005 14:34:25 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Czu-00089P-JK for speechsc@ietf.org; Mon, 08 Aug 2005 15:09:19 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 08 Aug 2005 11:34:12 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j78IYAQM007144 for ; Mon, 8 Aug 2005 11:34:10 -0700 (PDT) Received: from [10.32.245.154] (stealth-10-32-245-154.cisco.com [10.32.245.154]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j78IVCnw016208 for ; Mon, 8 Aug 2005 11:31:13 -0700 Mime-Version: 1.0 (Apple Message framework v733) Content-Transfer-Encoding: 7bit Message-Id: <1424D740-50C9-4D7B-8AE5-40E7AF5E7681@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "IETF SPEECHSC (E-mail)" From: David R Oran Date: Mon, 8 Aug 2005 14:34:03 -0400 X-Mailer: Apple Mail (2.733) DKIM-Signature: a=rsa-sha1; q=dns; l=1635; t=1123525873; x=1123958073; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=oran@cisco.com; z=Subject:Driving=20toward=20Last=20Call=20on=20MRCPv2| From:David=20R=20Oran=20| Date:Mon,=208=20Aug=202005=2014=3A34=3A03=20-0400| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=Gx4N3trhx5oNtLNxIX+vdNMuXR/FGmV17noRlrwGdb4vRciPWW6RcmX+7W66SGJSaFX3CbcE z6BfQ1AqP01lraExSRnSnOZ2P4a9YFJvvnPQwzI5LGAolKC5ko98Yq6LTxF7wGKfpKHXtwS3WVk 8xPjk8PWHUhkBwHrTx0BAxoY= Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Subject: [Speechsc] Driving toward Last Call on MRCPv2 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org By now you folks should have noticed that -07 was posted by Sarvi. This was a major revision, incorporating resolutions to the vast majority of the open issues, a conversion from Word to XML source, and a comprehensive technical and editorial review by both co-chairs. If you haven't already, you can get it from: http://www.ietf.org/internet-drafts/draft-ietf-speechsc-mrcpv2-07.txt In order to keep track of the issues raised on the mailing list and to manage the editing process, the chairs and authors have been using the "roundup" issue tracking tool. It is being hosted on softarmor.com with the gracious help of Dean Willis. We kept it private for the creation of -07, but are now ready to open it to the whole working group to review the changes and see the status of the remaining open issues. Please navigate to https://www.softarmor.com/roundup/speechsc/ and register yourself to access the issues list. The chairs would like to have no more than one further revision of the specification and be ready for WG last call by the end of August. Therefore, please: - make sure any issues you have reaised and were supposed to be addressed in -07 in fact have been marked resolved in the issue tracker and correctly reflected in -07 - review the open issues and indicate on the mailing list if there you feel their are any which MUST be resolved prior to going to last call. Unless we hear otherwise, we would like to defer non-critical functionality from this version of MRCP so we can get to proposed standard soon. We would like to declare rough consensus on each of the open issues as soon as feasible, and surface any new issues and deal with them expeditiously. I know this is mid-summer and people have lots of other things to think about. Some of your time and energy on this effort will be of great assistance to the working group in completing our main piece of technical work with minimal further delay. Thanks and Regards, Dave Oran (speechsc co-chair). _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Aug 10 14:35:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2vQc-0004RB-2s; Wed, 10 Aug 2005 14:35:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2vQa-0004R0-6Y; Wed, 10 Aug 2005 14:35:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15851; Wed, 10 Aug 2005 14:35:44 -0400 (EDT) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2vyh-00073O-QZ; Wed, 10 Aug 2005 15:11:04 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j7AIZVkQ067784; Wed, 10 Aug 2005 14:35:31 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7AIZHfN542920; Wed, 10 Aug 2005 12:35:17 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j7AIZU7p014735; Wed, 10 Aug 2005 12:35:30 -0600 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j7AIZUwM014717; Wed, 10 Aug 2005 12:35:30 -0600 In-Reply-To: <08d701c566be$d6931530$020aa8c0@db01.voxpilot.com> To: "Dave Burke" MIME-Version: 1.0 Subject: Re: [Speechsc] EMMA: Extensible MultiModal Annotation markup language support? X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Brett Gavagni Date: Wed, 10 Aug 2005 14:35:42 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.5.4|March 27, 2005) at 08/10/2005 12:35:50, Serialize complete at 08/10/2005 12:35:50 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: speechsc@ietf.org, "David R. Oran" , speechsc-bounces@ietf.org, Jerry Carter , "Reifenrath, Klaus" X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org What's the status of this request as it doesn't appear to have been addressed in the 07 draft or the roundup tool? Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com "Dave Burke" Sent by: speechsc-bounces@ietf.org 06/01/2005 11:30 AM To "David R. Oran" , "Reifenrath, Klaus" cc speechsc@ietf.org, Jerry Carter Subject Re: [Speechsc] EMMA: Extensible MultiModal Annotation markup language support? Having experienced the pain of several MRCPv1 ASR integrations (almost exclusively because of the previously insufficiently defined reco results), we agree with the comment for "stable base for development and deployment". Worried that even a "MAY support EMMA" is damaging but think it a reasonable compromise to add an informative note pointing out that the intent is to incorporate EMMA when it is a stable standard. This way the direction is clear and we don't have to revisit this question bimonthly! -- Dave ----- Original Message ----- From: "David R. Oran" To: "Reifenrath, Klaus" Cc: ; "Jerry Carter" Sent: Wednesday, June 01, 2005 3:07 PM Subject: Re: [Speechsc] EMMA: Extensible MultiModal Annotation markup language support? > **Chair hat on** > > The WG consensus, established over a number of IETF meetings and mailing > list discussion, was to publish MRCPv2 with the embedded NLSML so that > implementations would have a stable base for development and initial > deployment. > > The intent has always been to incorporate EMMA once it was deemed fully > cooked. > > If the WG wants to revisit this consensus in light of the fact we will be > going to last call on MRCPv2 imminently, I'll certainly entertain that > possibility. > > Dave. > > > On Jun 1, 2005, at 9:50 AM, Reifenrath, Klaus wrote: > >> Hi Brett, >> >> right, NLSML did not become a W3C Recommendation. Therefore the MRCPv2 >> spec >> includes a definition of NLSML (see sections 9.6 and A.2.1 in the 06 >> version >> of MRCPv2). >> >> Klaus >> >> -----Original Message----- >> From: Brett Gavagni [mailto:gavagni@us.ibm.com] >> Sent: Mittwoch, 1. Juni 2005 15:34 >> To: Jerry Carter >> Cc: speechsc@ietf.org >> Subject: Re: [Speechsc] EMMA: Extensible MultiModal Annotation markup >> language support? >> >> The current W3 NLSML specification is also a "W3 Working Draft" and not >> a >> "W3 Recommendation". >> >> http://www.w3.org/TR/nl-spec/ >> Natural Language Semantics Markup Language for the Speech Interface >> Framework >> >> W3C Working Draft 20 November 2000 >> >> The current NLSML specification is actually more outdated in terms of >> the >> function required to support the current SGRS specification (ie. >> Semantic >> Interpretation). >> >> My suggestion would be to amend the current MRCPv2 specification to >> include >> EMMA support as at least optional. >> >> Thanks, >> >> Brett Gavagni >> WebSphere Voice Server Development >> http://www-306.ibm.com/software/pervasive/voice_server/ >> (561) 862-2097 T/L (975) >> gavagni@us.ibm.com >> >> >> >> >> Jerry Carter >> 06/01/2005 09:16 AM >> >> To >> Brett Gavagni/West Palm Beach/IBM@IBMUS >> cc >> speechsc@ietf.org >> Subject >> Re: [Speechsc] EMMA: Extensible MultiModal Annotation markup language >> support? >> >> >> >> >> >> >> Give that EMMA is at working draft level within the W3C, it would be >> premature to require any form of EMMA support. Making a provision in >> MRCP to support EMMA at a later date would be appropriate, though. >> >> On Jun 1, 2005, at 8:59 AM, Brett Gavagni wrote: >> >> >>> Are there currently any plans to include the support for W3C EMMA >>> Working >>> Draft to the MRCPv2 specification for the returning of recognition >>> results? >>> >>> Thanks, >>> >>> Brett Gavagni >>> WebSphere Voice Server Development >>> http://www-306.ibm.com/software/pervasive/voice_server/ >>> (561) 862-2097 T/L (975) >>> gavagni@us.ibm.com >>> >>> >>> _______________________________________________ >>> Speechsc mailing list >>> Speechsc@ietf.org >>> https://www1.ietf.org/mailman/listinfo/speechsc >>> >>> >> >> >> >> >> _______________________________________________ >> Speechsc mailing list >> Speechsc@ietf.org >> https://www1.ietf.org/mailman/listinfo/speechsc >> >> _______________________________________________ >> Speechsc mailing list >> Speechsc@ietf.org >> https://www1.ietf.org/mailman/listinfo/speechsc >> > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Aug 10 14:43:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2vXe-0006NN-Ph; Wed, 10 Aug 2005 14:43:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2vXd-0006NH-RB for speechsc@megatron.ietf.org; Wed, 10 Aug 2005 14:43:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16927 for ; Wed, 10 Aug 2005 14:43:04 -0400 (EDT) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2w5m-0007UM-Q0 for speechsc@ietf.org; Wed, 10 Aug 2005 15:18:24 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j7AIgsxk380494 for ; Wed, 10 Aug 2005 14:42:54 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7AIgefN546928 for ; Wed, 10 Aug 2005 12:42:40 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j7AIgrSp018646 for ; Wed, 10 Aug 2005 12:42:53 -0600 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j7AIgrJn018638 for ; Wed, 10 Aug 2005 12:42:53 -0600 In-Reply-To: To: speechsc@ietf.org MIME-Version: 1.0 Subject: Re: [Speechsc] Personal-Grammar-URI clarification X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Brett Gavagni Date: Wed, 10 Aug 2005 14:43:11 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.5.4|March 27, 2005) at 08/10/2005 12:43:12, Serialize complete at 08/10/2005 12:43:12 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Bump Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com Brett Gavagni/West Palm Beach/IBM@IBMUS Sent by: speechsc-bounces@ietf.org 07/26/2005 11:28 AM To speechsc@ietf.org cc Subject [Speechsc] Personal-Grammar-URI clarification Hi, The wording throughout the current draft specification is a bit confusing w.r.t "Personal-Grammar-URI". Is the expectation that the "Personal-Grammar-URI" value is merely a client specified handle to an external grammar in lieu of using a "Content-Id" value? Is the expectation that the server persistently store these references and the backing grammars, and when and how would the release of these references occur? Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Aug 10 14:55:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2vjS-0003uq-RQ; Wed, 10 Aug 2005 14:55:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2vjR-0003ui-HX; Wed, 10 Aug 2005 14:55:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18961; Wed, 10 Aug 2005 14:55:16 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2wHb-0008MP-AF; Wed, 10 Aug 2005 15:30:35 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 10 Aug 2005 11:55:08 -0700 Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j7AIt4Z1017072; Wed, 10 Aug 2005 11:55:04 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] EMMA: Extensible MultiModal Annotation markup languagesupport? Date: Wed, 10 Aug 2005 11:55:03 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C2C3902@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] EMMA: Extensible MultiModal Annotation markup languagesupport? Thread-Index: AcWd2zoK+6orY+o8T9a0hqQrN9oTRQAAbScg From: "Shanmugham, Saravanan" To: "Brett Gavagni" , "Dave Burke" X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Content-Transfer-Encoding: quoted-printable Cc: speechsc@ietf.org, "David R. Oran" , speechsc-bounces@ietf.org, Jerry Carter , "Reifenrath, Klaus" X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Added to this list. The text proposed by Dave will be added to the next draft. Sarvi=20 -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni Sent: Wednesday, August 10, 2005 11:36 AM To: Dave Burke Cc: speechsc@ietf.org; David R. Oran;=20 speechsc-bounces@ietf.org; Jerry Carter; Reifenrath, Klaus Subject: Re: [Speechsc] EMMA: Extensible MultiModal=20 Annotation markup languagesupport? =20 What's the status of this request as it doesn't appear to=20 have been addressed in the 07 draft or the roundup tool? =20 Thanks, =20 Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com =20 =20 =20 =20 "Dave Burke" Sent by:=20 speechsc-bounces@ietf.org 06/01/2005 11:30 AM =20 To "David R. Oran" , "Reifenrath, Klaus"=20 cc speechsc@ietf.org, Jerry Carter Subject Re: [Speechsc] EMMA: Extensible MultiModal Annotation=20 markup language support? =20 =20 =20 =20 =20 =20 Having experienced the pain of several MRCPv1 ASR=20 integrations (almost=20 exclusively because of the previously insufficiently defined reco=20 results),=20 we agree with the comment for "stable base for development and=20 deployment". =20 Worried that even a "MAY support EMMA" is damaging but think it a=20 reasonable=20 compromise to add an informative note pointing out that=20 the intent is to=20 incorporate EMMA when it is a stable standard. This way=20 the direction is=20 clear and we don't have to revisit this question bimonthly! =20 -- Dave =20 ----- Original Message -----=20 From: "David R. Oran" To: "Reifenrath, Klaus" Cc: ; "Jerry Carter" Sent: Wednesday, June 01, 2005 3:07 PM Subject: Re: [Speechsc] EMMA: Extensible MultiModal=20 Annotation markup=20 language support? =20 =20 > **Chair hat on** > > The WG consensus, established over a number of IETF=20 meetings and mailing=20 =20 > list discussion, was to publish MRCPv2 with the embedded=20 NLSML so that=20 > implementations would have a stable base for =20 development and initial=20 > deployment. > > The intent has always been to incorporate EMMA once it=20 was deemed fully=20 =20 > cooked. > > If the WG wants to revisit this consensus in light of=20 the fact we will=20 be=20 > going to last call on MRCPv2 imminently, I'll certainly =20 entertain that=20 > possibility. > > Dave. > > > On Jun 1, 2005, at 9:50 AM, Reifenrath, Klaus wrote: > >> Hi Brett, >> >> right, NLSML did not become a W3C Recommendation.=20 Therefore the MRCPv2=20 =20 >> spec >> includes a definition of NLSML (see sections 9.6 and=20 A.2.1 in the 06=20 >> version >> of MRCPv2). >> >> Klaus >> >> -----Original Message----- >> From: Brett Gavagni [mailto:gavagni@us.ibm.com] >> Sent: Mittwoch, 1. Juni 2005 15:34 >> To: Jerry Carter >> Cc: speechsc@ietf.org >> Subject: Re: [Speechsc] EMMA: Extensible MultiModal=20 Annotation markup >> language support? >> >> The current W3 NLSML specification is also a "W3=20 Working Draft" and not=20 =20 >> a >> "W3 Recommendation". >> >> http://www.w3.org/TR/nl-spec/ >> Natural Language Semantics Markup Language for the=20 Speech Interface >> Framework >> >> W3C Working Draft 20 November 2000 >> >> The current NLSML specification is actually more=20 outdated in terms of=20 >> the >> function required to support the current SGRS=20 specification (ie.=20 >> Semantic >> Interpretation). >> >> My suggestion would be to amend the current MRCPv2=20 specification to=20 >> include >> EMMA support as at least optional. >> >> Thanks, >> >> Brett Gavagni >> WebSphere Voice Server Development >> http://www-306.ibm.com/software/pervasive/voice_server/ >> (561) 862-2097 T/L (975) >> gavagni@us.ibm.com >> >> >> >> >> Jerry Carter >> 06/01/2005 09:16 AM >> >> To >> Brett Gavagni/West Palm Beach/IBM@IBMUS >> cc >> speechsc@ietf.org >> Subject >> Re: [Speechsc] EMMA: Extensible MultiModal Annotation=20 markup language >> support? >> >> >> >> >> >> >> Give that EMMA is at working draft level within the=20 W3C, it would be >> premature to require any form of EMMA support. Making=20 a provision in >> MRCP to support EMMA at a later date would be=20 appropriate, though. >> >> On Jun 1, 2005, at 8:59 AM, Brett Gavagni wrote: >> >> >>> Are there currently any plans to include the support=20 for W3C EMMA >>> Working >>> Draft to the MRCPv2 specification for the returning of=20 recognition >>> results? >>> >>> Thanks, >>> >>> Brett Gavagni >>> WebSphere Voice Server Development >>> http://www-306.ibm.com/software/pervasive/voice_server/ >>> (561) 862-2097 T/L (975) >>> gavagni@us.ibm.com >>> >>> >>> _______________________________________________ >>> Speechsc mailing list >>> Speechsc@ietf.org >>> https://www1.ietf.org/mailman/listinfo/speechsc >>> >>> >> >> >> >> >> _______________________________________________ >> Speechsc mailing list >> Speechsc@ietf.org >> https://www1.ietf.org/mailman/listinfo/speechsc >> >> _______________________________________________ >> Speechsc mailing list >> Speechsc@ietf.org >> https://www1.ietf.org/mailman/listinfo/speechsc >> > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc >=20 =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Aug 10 16:03:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2wns-0000DD-Vf; Wed, 10 Aug 2005 16:03:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2wnr-00006c-AY for speechsc@megatron.ietf.org; Wed, 10 Aug 2005 16:03:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27965 for ; Wed, 10 Aug 2005 16:03:53 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2xM1-0003Ol-5C for speechsc@ietf.org; Wed, 10 Aug 2005 16:39:13 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 10 Aug 2005 13:03:45 -0700 X-IronPort-AV: i="3.96,97,1122879600"; d="scan'208"; a="204041073:sNHT30932332" Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j7AK3eZ3024511; Wed, 10 Aug 2005 13:03:42 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Personal-Grammar-URI clarification Date: Wed, 10 Aug 2005 13:03:41 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C2C392A@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] Personal-Grammar-URI clarification Thread-Index: AcWd26R/Ig6cKD/STkyx3yPzjS/YcQAAWWvw From: "Shanmugham, Saravanan" To: "Brett Gavagni" , X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org I am not sure what you mean by its relationship to Content-Id. To me Personal-Grammar-URI is just like anyother grammar that has a list of items.=20 Except that it is constructed by the user adding individual phrases to that one-of list during enrollment. Once enrolled, the usage of that grammar should be no different from any other grammar. This could be a HTTP URI in which case the MRCP server uses HTTP GET/PUT to modify that grammar during enrollment. So to answer your question, the MRCP server is not expected to store this personal grammar, but would be create/modified at the URI specified by the personal grammar URI. Sarvi -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni Sent: Wednesday, August 10, 2005 11:43 AM To: speechsc@ietf.org Subject: Re: [Speechsc] Personal-Grammar-URI clarification =20 Bump =20 Thanks, =20 Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com =20 =20 =20 =20 Brett Gavagni/West Palm Beach/IBM@IBMUS Sent by:=20 speechsc-bounces@ietf.org 07/26/2005 11:28 AM =20 To speechsc@ietf.org cc =20 Subject [Speechsc] Personal-Grammar-URI clarification =20 =20 =20 =20 =20 =20 Hi, =20 The wording throughout the current draft specification is=20 a bit confusing w.r.t "Personal-Grammar-URI". =20 Is the expectation that the "Personal-Grammar-URI" value=20 is merely a client specified handle to an external grammar=20 in lieu of using a "Content-Id" value? =20 Is the expectation that the server persistently store=20 these references and=20 =20 the backing grammars, and when and how would the release=20 of these references occur? =20 Thanks, =20 Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Aug 17 10:36:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5P1l-0006ur-FN; Wed, 17 Aug 2005 10:36:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5P1k-0006um-9p for speechsc@megatron.ietf.org; Wed, 17 Aug 2005 10:36:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04634 for ; Wed, 17 Aug 2005 10:36:22 -0400 (EDT) Received: from letter.nuance.com ([207.107.210.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5PbJ-0001L4-5K for speechsc@ietf.org; Wed, 17 Aug 2005 11:13:09 -0400 Received: from postcard.nuance.com ([10.3.6.20]:21184) by letter.nuance.com with esmtp id 1E5P1W-0008Ss-Rg for speechsc@ietf.org; Wed, 17 Aug 2005 07:36:10 -0700 Received: from mtb1exch01.nuance.com ([10.3.2.6]) by postcard.nuance.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 17 Aug 2005 10:36:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] I-D ACTION:draft-ietf-speechsc-mrcpv2-07.txt Date: Wed, 17 Aug 2005 10:36:04 -0400 Message-ID: <7DE7C4EF3B7C8B4B82955191378290D8030F65AA@mtb1exch01.nuance.com> Thread-Topic: [Speechsc] I-D ACTION:draft-ietf-speechsc-mrcpv2-07.txt Thread-Index: AcWW1lk3cgJ+fpmySA+LBlxcCdmm2gMYmAhg From: "Pierre Forgues" To: X-OriginalArrivalTime: 17 Aug 2005 14:36:05.0677 (UTC) FILETIME=[FFE745D0:01C5A338] X-FromHost: postcard.nuance.com [10.3.6.20]:21184 Lines: 87 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org When is the MRCP draft document going to be revised with the synthesizer and recognizer usage tables included? The following text in draft 07 needs to be replaced with the actual table (same for the recognizer resource): SYNTHESIZER HEADER USAGE TABLE TEMPORARILY REMOVED DUE TO XML2RFC LAYOUT PROBLEMS Thanks, Pierre -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, August 01, 2005 3:50 PM To: i-d-announce@ietf.org Cc: speechsc@ietf.org Subject: [Speechsc] I-D ACTION:draft-ietf-speechsc-mrcpv2-07.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Speech Services Control Working Group of the IETF. Title : Media Resource Control Protocol Version 2 (MRCPv2) Author(s) : D. Burnett, S. Shanmugham Filename : draft-ietf-speechsc-mrcpv2-07.txt Pages : 198 Date : 2005-8-1 =09 The MRCPv2 protocol allows client hosts to control media service resources such as speech synthesizers, recognizers, verifiers and identifiers residing in servers on the network. MRCPv2 is not a "stand-alone" protocol - it relies on a session management protocol such as the Session Initiation Protocol (SIP) to establish the MRCPv2 control session between the client and the server, and for rendezvous and capability discovery. It also depends on SIP and SDP to establish the media sessions and associated parameters between the media source or sink and the media server. Once this is done, the MRCPv2 protocol exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speechsc-mrcpv2-07.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-speechsc-mrcpv2-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-speechsc-mrcpv2-07.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Aug 17 11:13:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Pbd-0000Ca-6C; Wed, 17 Aug 2005 11:13:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Pbb-0000CV-IL for speechsc@megatron.ietf.org; Wed, 17 Aug 2005 11:13:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06719 for ; Wed, 17 Aug 2005 11:13:25 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5QB8-0002Sy-JX for speechsc@ietf.org; Wed, 17 Aug 2005 11:50:13 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 17 Aug 2005 08:13:16 -0700 X-IronPort-AV: i="3.96,117,1122879600"; d="scan'208"; a="205482690:sNHT34705992" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j7HFDD2i003262; Wed, 17 Aug 2005 08:13:13 -0700 (PDT) Received: from [10.32.245.155] (stealth-10-32-245-155.cisco.com [10.32.245.155]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j7HF9gOS031175; Wed, 17 Aug 2005 08:09:43 -0700 In-Reply-To: <7DE7C4EF3B7C8B4B82955191378290D8030F65AA@mtb1exch01.nuance.com> References: <7DE7C4EF3B7C8B4B82955191378290D8030F65AA@mtb1exch01.nuance.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6D3193E5-7AF9-46C9-9E67-D18A202DFE4F@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Speechsc] I-D ACTION:draft-ietf-speechsc-mrcpv2-07.txt Date: Wed, 17 Aug 2005 11:13:10 -0400 To: "Pierre Forgues" X-Mailer: Apple Mail (2.734) DKIM-Signature: a=rsa-sha1; q=dns; l=3514; t=1124291383; x=1124723583; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=oran@cisco.com; z=Subject:Re=3A=20[Speechsc]=20I-D=20ACTION=3Adraft-ietf-speechsc-mrcpv2-07.txt=20| From:David=20R=20Oran=20| Date:Wed,=2017=20Aug=202005=2011=3A13=3A10=20-0400| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=HY1qCrALQHmgEACSPmh8OZ9C8APnWbfgAtsNcZbNusyfxo0Li2NXbWwvRq69IEgzOwuQ6beJ S+pmtyjcEnYF8J7N0jjCJGXWMRGcRuXS4DJ3hqJnfpe1XlSUPXZ86ALsWUfiT7RdVem8Y2JXNFK HZVtfRycR4eZrLOHMxBNvkqY= Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org On Aug 17, 2005, at 10:36 AM, Pierre Forgues wrote: > When is the MRCP draft document going to be revised with the > synthesizer > and recognizer usage tables included? The following text in draft 07 > needs to be replaced with the actual table (same for the recognizer > resource): > > SYNTHESIZER HEADER USAGE TABLE TEMPORARILY REMOVED DUE TO XML2RFC > LAYOUT PROBLEMS > Maybe never, if we can't figure out a way to coax XML2RFC into meeting the 72-character line limit imposed by the RFC-editor, or figure out a way to re-layout the tables in a way that makes them fit. How'd you like to take a crack at this? I already wasted a number of hours. BTW: In the case of other specs (e.g. SIP) the community has come to the tentative conclusion that the tables are a maintenance/ consistency nightmare and might be better left out in the first place. It's an option we should consider... Dave. > Thanks, > Pierre > > -----Original Message----- > From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On > Behalf Of Internet-Drafts@ietf.org > Sent: Monday, August 01, 2005 3:50 PM > To: i-d-announce@ietf.org > Cc: speechsc@ietf.org > Subject: [Speechsc] I-D ACTION:draft-ietf-speechsc-mrcpv2-07.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Speech Services Control Working Group > of the IETF. > > Title : Media Resource Control Protocol Version 2 > (MRCPv2) > Author(s) : D. Burnett, S. Shanmugham > Filename : draft-ietf-speechsc-mrcpv2-07.txt > Pages : 198 > Date : 2005-8-1 > > The MRCPv2 protocol allows client hosts to control media service > resources such as speech synthesizers, recognizers, verifiers and > identifiers residing in servers on the network. MRCPv2 is not a > "stand-alone" protocol - it relies on a session management protocol > such as the Session Initiation Protocol (SIP) to establish the > MRCPv2 > control session between the client and the server, and for > rendezvous > and capability discovery. It also depends on SIP and SDP to > establish the media sessions and associated parameters between the > media source or sink and the media server. Once this is done, the > MRCPv2 protocol exchange operates over the control session > established above, allowing the client to control the media > processing resources on the speech resource server. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-speechsc-mrcpv2-07.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-speechsc-mrcpv2-07.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-speechsc-mrcpv2-07.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Aug 17 11:38:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Q0J-0007ac-GV; Wed, 17 Aug 2005 11:38:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Q0H-0007aQ-LS for speechsc@megatron.ietf.org; Wed, 17 Aug 2005 11:38:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07832 for ; Wed, 17 Aug 2005 11:38:53 -0400 (EDT) Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5QZn-0003BV-MV for speechsc@ietf.org; Wed, 17 Aug 2005 12:15:41 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j7HFcg8E289834 for ; Wed, 17 Aug 2005 11:38:42 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7HFcjvx200560 for ; Wed, 17 Aug 2005 09:38:45 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j7HFcfWx012244 for ; Wed, 17 Aug 2005 09:38:41 -0600 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j7HFcfmG012235 for ; Wed, 17 Aug 2005 09:38:41 -0600 In-Reply-To: <03772D1EC8DE624A863058C75874A75C2C392A@vtg-um-e2k6.sj21ad.cisco.com> To: "Shanmugham, Saravanan" MIME-Version: 1.0 Subject: RE: [Speechsc] Personal-Grammar-URI clarification X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Brett Gavagni Date: Wed, 17 Aug 2005 11:38:43 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.5.4|March 27, 2005) at 08/17/2005 09:38:45, Serialize complete at 08/17/2005 09:38:45 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Thanks for the clarification! Since SRGS defines syntactical support for both ABNF and XML formats, it may be useful to add some wording or modify the "Personal-Grammar-URI" examples to specify the "Content-Type". This may assist in facilitating client/server interoperability. Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com "Shanmugham, Saravanan" 08/10/2005 04:03 PM To Brett Gavagni/West Palm Beach/IBM@IBMUS, cc Subject RE: [Speechsc] Personal-Grammar-URI clarification I am not sure what you mean by its relationship to Content-Id. To me Personal-Grammar-URI is just like anyother grammar that has a list of items. Except that it is constructed by the user adding individual phrases to that one-of list during enrollment. Once enrolled, the usage of that grammar should be no different from any other grammar. This could be a HTTP URI in which case the MRCP server uses HTTP GET/PUT to modify that grammar during enrollment. So to answer your question, the MRCP server is not expected to store this personal grammar, but would be create/modified at the URI specified by the personal grammar URI. Sarvi -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni Sent: Wednesday, August 10, 2005 11:43 AM To: speechsc@ietf.org Subject: Re: [Speechsc] Personal-Grammar-URI clarification Bump Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com Brett Gavagni/West Palm Beach/IBM@IBMUS Sent by: speechsc-bounces@ietf.org 07/26/2005 11:28 AM To speechsc@ietf.org cc Subject [Speechsc] Personal-Grammar-URI clarification Hi, The wording throughout the current draft specification is a bit confusing w.r.t "Personal-Grammar-URI". Is the expectation that the "Personal-Grammar-URI" value is merely a client specified handle to an external grammar in lieu of using a "Content-Id" value? Is the expectation that the server persistently store these references and the backing grammars, and when and how would the release of these references occur? Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Aug 17 12:06:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5QRE-0004zm-Pu; Wed, 17 Aug 2005 12:06:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5QRA-0004zM-Qs for speechsc@megatron.ietf.org; Wed, 17 Aug 2005 12:06:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08942 for ; Wed, 17 Aug 2005 12:06:42 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5R0j-0003sa-Dy for speechsc@ietf.org; Wed, 17 Aug 2005 12:43:30 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 17 Aug 2005 09:06:35 -0700 X-IronPort-AV: i="3.96,117,1122879600"; d="scan'208"; a="205506321:sNHT34066152" Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j7HFqjZ1027107; Wed, 17 Aug 2005 08:52:45 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Personal-Grammar-URI clarification Date: Wed, 17 Aug 2005 08:52:44 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C2C3D57@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] Personal-Grammar-URI clarification Thread-Index: AcWjQfxwQyRGkh52TD6qvphj/LPmJwAAZsYw From: "Shanmugham, Saravanan" To: "Brett Gavagni" X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: quoted-printable Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Don't understand. Could you please clarify and Propose some text. Sarvi=20 -----Original Message----- From: Brett Gavagni [mailto:gavagni@us.ibm.com]=20 Sent: Wednesday, August 17, 2005 8:39 AM To: Shanmugham, Saravanan Cc: speechsc@ietf.org Subject: RE: [Speechsc] Personal-Grammar-URI clarification =20 Thanks for the clarification! =20 Since SRGS defines syntactical support for both ABNF and=20 XML formats, it may be useful to add some wording or=20 modify the "Personal-Grammar-URI"=20 examples to specify the "Content-Type". =20 This may assist in facilitating client/server interoperability.=20 =20 Thanks, =20 Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com =20 =20 =20 =20 "Shanmugham, Saravanan" 08/10/2005 04:03 PM =20 To Brett Gavagni/West Palm Beach/IBM@IBMUS, cc =20 Subject RE: [Speechsc] Personal-Grammar-URI clarification =20 =20 =20 =20 =20 =20 I am not sure what you mean by its relationship to Content-Id. =20 To me Personal-Grammar-URI is just like anyother grammar=20 that has a list of items.=20 Except that it is constructed by the user adding=20 individual phrases to that one-of list during enrollment. =20 Once enrolled, the usage of that grammar should be no=20 different from any other grammar. =20 This could be a HTTP URI in which case the MRCP server=20 uses HTTP GET/PUT to modify that grammar during=20 enrollment. So to answer your question, the MRCP server is=20 not expected to store this personal grammar, but would be=20 create/modified at the URI specified by the personal grammar URI. =20 Sarvi =20 -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni Sent: Wednesday, August 10, 2005 11:43 AM To: speechsc@ietf.org Subject: Re: [Speechsc] Personal-Grammar-URI clarification =20 Bump =20 Thanks, =20 Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com =20 =20 =20 =20 Brett Gavagni/West Palm Beach/IBM@IBMUS Sent by:=20 speechsc-bounces@ietf.org 07/26/2005 11:28 AM =20 To speechsc@ietf.org cc =20 Subject [Speechsc] Personal-Grammar-URI clarification =20 =20 =20 =20 =20 =20 Hi, =20 The wording throughout the current draft specification is=20 a bit confusing w.r.t "Personal-Grammar-URI". =20 Is the expectation that the "Personal-Grammar-URI" value=20 is merely a client specified handle to an external grammar=20 in lieu of using a "Content-Id" value? =20 Is the expectation that the server persistently store=20 these references and=20 =20 the backing grammars, and when and how would the release=20 of these references occur? =20 Thanks, =20 Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Aug 17 12:30:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Qnn-0005L3-DC; Wed, 17 Aug 2005 12:30:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Qnm-0005Kx-OX for speechsc@megatron.ietf.org; Wed, 17 Aug 2005 12:30:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10403 for ; Wed, 17 Aug 2005 12:30:04 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5RNM-0004fG-Ew for speechsc@ietf.org; Wed, 17 Aug 2005 13:06:52 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 17 Aug 2005 09:29:57 -0700 X-IronPort-AV: i="3.96,118,1122879600"; d="scan'208"; a="205520309:sNHT32946580" Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j7HF6x2i000818; Wed, 17 Aug 2005 08:07:00 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] I-D ACTION:draft-ietf-speechsc-mrcpv2-07.txt Date: Wed, 17 Aug 2005 08:06:58 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C2C3D4E@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] I-D ACTION:draft-ietf-speechsc-mrcpv2-07.txt Thread-Index: AcWW1lk3cgJ+fpmySA+LBlxcCdmm2gMYmAhgAAEXFBA= From: "Shanmugham, Saravanan" To: "Pierre Forgues" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org That should text should go. My bad. Will take care of it in the next rev.=20 But per dave's feed back this is pretty complex to maintain, we will not be adding it back. Sarvi=20 -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Pierre Forgues Sent: Wednesday, August 17, 2005 7:36 AM To: speechsc@ietf.org Subject: RE: [Speechsc] I-D=20 ACTION:draft-ietf-speechsc-mrcpv2-07.txt=20 =20 When is the MRCP draft document going to be revised with=20 the synthesizer and recognizer usage tables included? The=20 following text in draft 07 needs to be replaced with the=20 actual table (same for the recognizer resource): =20 SYNTHESIZER HEADER USAGE TABLE TEMPORARILY REMOVED DUE=20 TO XML2RFC LAYOUT PROBLEMS =20 Thanks, Pierre =20 -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of=20 Internet-Drafts@ietf.org Sent: Monday, August 01, 2005 3:50 PM To: i-d-announce@ietf.org Cc: speechsc@ietf.org Subject: [Speechsc] I-D ACTION:draft-ietf-speechsc-mrcpv2-07.txt=20 =20 A New Internet-Draft is available from the on-line=20 Internet-Drafts directories. This draft is a work item of the Speech Services Control=20 Working Group of the IETF. =20 Title : Media Resource Control Protocol Version 2 (MRCPv2) Author(s) : D. Burnett, S. Shanmugham Filename : draft-ietf-speechsc-mrcpv2-07.txt Pages : 198 Date : 2005-8-1 =09 The MRCPv2 protocol allows client hosts to control media service resources such as speech synthesizers, recognizers,=20 verifiers and identifiers residing in servers on the network. MRCPv2 is not a "stand-alone" protocol - it relies on a session=20 management protocol such as the Session Initiation Protocol (SIP) to=20 establish the MRCPv2 control session between the client and the server, and=20 for rendezvous and capability discovery. It also depends on SIP and SDP to establish the media sessions and associated parameters=20 between the media source or sink and the media server. Once this=20 is done, the MRCPv2 protocol exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server. =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speechsc-mrc pv2-07.txt =20 To remove yourself from the I-D Announcement list, send a=20 message to i-d-announce-request@ietf.org with the word=20 unsubscribe in the body of the message. =20 You can also visit=20 https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. =20 =20 Internet-Drafts are also available by anonymous FTP. Login=20 with the username "anonymous" and a password of your=20 e-mail address. After logging in, type "cd=20 internet-drafts" and then "get draft-ietf-speechsc-mrcpv2-07.txt". =20 A list of Internet-Drafts directories can be found in=20 http://www.ietf.org/shadow.html or=20 ftp://ftp.ietf.org/ietf/1shadow-sites.txt =20 =20 Internet-Drafts can also be obtained by e-mail. =20 Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-speechsc-mrcpv2-07.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Mon Aug 22 06:05:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E79B0-00080q-I3; Mon, 22 Aug 2005 06:05:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E79Az-00080k-Ah for speechsc@megatron.ietf.org; Mon, 22 Aug 2005 06:05:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04202 for ; Mon, 22 Aug 2005 06:05:03 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E79lM-0002xX-FE for speechsc@ietf.org; Mon, 22 Aug 2005 06:42:52 -0400 Received: from daburkewxp (unknown [217.75.6.130]) by mail.voxpilot.com (Postfix) with ESMTP id A2772214046; Mon, 22 Aug 2005 10:04:37 +0000 (GMT) Message-ID: <1d2f01c5a700$ea24dc50$0a01a8c0@db01.voxpilot.com> From: "Dave Burke" To: "IETF SPEECHSC (E-mail)" , "David R Oran" References: <1424D740-50C9-4D7B-8AE5-40E7AF5E7681@cisco.com> Subject: Re: [Speechsc] Driving toward Last Call on MRCPv2 Date: Mon, 22 Aug 2005 11:04:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Hello, Version 7 looks good to me (nice job). Some bugs / features not being tracked as far as I can see: Bugs: ------- A. We decided to remove phrase "media server" - e.g. http://www.ietf.org/mail-archive/web/speechsc/current/msg00631.html. Looks like v7 has cleaned this up nicely except for the Abstract. Change "media service resources" to "media processing resources" and "media server" to "media processing server" for consistency with rest of text. Features: ------------ B. Managing big grammars: http://www.ietf.org/mail-archive/web/speechsc/current/msg01404.html. What I believe was agreeable: 1. Note that MRCP servers may choose to centrally cache grammars 2. Note that the MRCP server may choose to use a stale grammar temporarily to avoid latency when a HTTP revalidation is compile but must return a Warning 3. Using Cache-Control: max-stale=0 overrides point 2 4. Grammar caching ought to be SHOULD not MAY 5. Are DEFINE-GRAMMAR handles (Content-Id) global? On one hand, we don't want to have to ship large payloads to the MRCP server every call (e.g. if grammar is inline). On the other, does an MRCP server have to remember the Content-Id<->URI or Content-Id<-> document mapping forever? So perhaps it has to be the former. At least the operation should be clarified... C. START-OF-INPUT to include a InputType field (dtmf or speech) - http://www1.ietf.org/mail-archive/web/speechsc/current/msg01454.html D. Track this at least for a future version. There is no mechanism for linking a control channel to more than one media stream as would be necessary for a video evolution. One simple approach (which at least illustrates the point) is to have a a=cmid:1,2 where a=mid:1 is an audio stream and a=mid:2 is a video stream. Alternatively use RFC 3388. We have a need for this today for support video media in VoiceXML. See - http://www.ietf.org/mail-archive/web/speechsc/current/msg01281.html - Dave ----- Original Message ----- From: "David R Oran" To: "IETF SPEECHSC (E-mail)" Sent: Monday, August 08, 2005 7:34 PM Subject: [Speechsc] Driving toward Last Call on MRCPv2 > By now you folks should have noticed that -07 was posted by Sarvi. This > was a major revision, incorporating resolutions to the vast majority of > the open issues, a conversion from Word to XML source, and a > comprehensive technical and editorial review by both co-chairs. > > If you haven't already, you can get it from: > http://www.ietf.org/internet-drafts/draft-ietf-speechsc-mrcpv2-07.txt > > In order to keep track of the issues raised on the mailing list and to > manage the editing process, the chairs and authors have been using the > "roundup" issue tracking tool. It is being hosted on softarmor.com with > the gracious help of Dean Willis. We kept it private for the creation > of -07, but are now ready to open it to the whole working group to review > the changes and see the status of the remaining open issues. > > Please navigate to https://www.softarmor.com/roundup/speechsc/ and > register yourself to access the issues list. > > The chairs would like to have no more than one further revision of the > specification and be ready for WG last call by the end of August. > Therefore, please: > - make sure any issues you have reaised and were supposed to be addressed > in -07 in fact have been marked resolved in the issue tracker and > correctly reflected in -07 > - review the open issues and indicate on the mailing list if there you > feel their are any which MUST be resolved prior to going to last call. > Unless we hear otherwise, we would like to defer non-critical > functionality from this version of MRCP so we can get to proposed > standard soon. > > We would like to declare rough consensus on each of the open issues as > soon as feasible, and surface any new issues and deal with them > expeditiously. > > I know this is mid-summer and people have lots of other things to think > about. Some of your time and energy on this effort will be of great > assistance to the working group in completing our main piece of technical > work with minimal further delay. > > Thanks and Regards, > Dave Oran (speechsc co-chair). > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Mon Aug 22 10:53:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Dg1-00083V-0w; Mon, 22 Aug 2005 10:53:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Dfy-00083L-E4 for speechsc@megatron.ietf.org; Mon, 22 Aug 2005 10:53:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20728 for ; Mon, 22 Aug 2005 10:53:22 -0400 (EDT) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7EGS-0003K3-8V for speechsc@ietf.org; Mon, 22 Aug 2005 11:31:09 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j7MEqswh106288 for ; Mon, 22 Aug 2005 10:52:55 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7MEr2h5090024 for ; Mon, 22 Aug 2005 08:53:02 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j7MEqrqA001999 for ; Mon, 22 Aug 2005 08:52:53 -0600 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j7MEqrbK001984 for ; Mon, 22 Aug 2005 08:52:53 -0600 To: speechsc@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Brett Gavagni Date: Mon, 22 Aug 2005 10:53:03 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.5.4|March 27, 2005) at 08/22/2005 08:53:04, Serialize complete at 08/22/2005 08:53:04 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Hi, What's the status of this request that was made a few months ago, as it doesn't appear to have been addressed in the -07 draft? Here's the thread on the topic: http://www1.ietf.org/mail-archive/web/speechsc/current/msg01234.html Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Mon Aug 22 11:14:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7E0T-0003Vv-Oa; Mon, 22 Aug 2005 11:14:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7E0S-0003VP-7u for speechsc@megatron.ietf.org; Mon, 22 Aug 2005 11:14:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21875 for ; Mon, 22 Aug 2005 11:14:31 -0400 (EDT) Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Eb0-0003yt-Bv for speechsc@ietf.org; Mon, 22 Aug 2005 11:52:22 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j7MFDT48614914 for ; Mon, 22 Aug 2005 11:13:30 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7MFDbh5187588 for ; Mon, 22 Aug 2005 09:13:37 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j7MFDSF6015165 for ; Mon, 22 Aug 2005 09:13:28 -0600 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j7MFDSSa015162 for ; Mon, 22 Aug 2005 09:13:28 -0600 In-Reply-To: <03772D1EC8DE624A863058C75874A75C2C3D57@vtg-um-e2k6.sj21ad.cisco.com> To: "Shanmugham, Saravanan" MIME-Version: 1.0 Subject: RE: [Speechsc] Personal-Grammar-URI clarification X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Brett Gavagni Date: Mon, 22 Aug 2005 11:13:38 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.5.4|March 27, 2005) at 08/22/2005 09:13:39, Serialize complete at 08/22/2005 09:13:39 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Thanks! I see the point, the MRCP server's HTTP PUT request should specify the "Content-Type" of "application/srgs" or "application/srgs+xml" as described in SRGS to indicate the grammar format. At the time, I was suggesting to add some wording similar to the following to section 9.4.35 Personal-Grammar-URI: The generated SRGS grammar syntax MAY be implementation specific. Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ (561) 862-2097 T/L (975) gavagni@us.ibm.com "Shanmugham, Saravanan" 08/17/2005 11:52 AM To Brett Gavagni/West Palm Beach/IBM@IBMUS cc Subject RE: [Speechsc] Personal-Grammar-URI clarification Don't understand. Could you please clarify and Propose some text. Sarvi -----Original Message----- From: Brett Gavagni [mailto:gavagni@us.ibm.com] Sent: Wednesday, August 17, 2005 8:39 AM To: Shanmugham, Saravanan Cc: speechsc@ietf.org Subject: RE: [Speechsc] Personal-Grammar-URI clarification Thanks for the clarification! Since SRGS defines syntactical support for both ABNF and XML formats, it may be useful to add some wording or modify the "Personal-Grammar-URI" examples to specify the "Content-Type". This may assist in facilitating client/server interoperability. Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com "Shanmugham, Saravanan" 08/10/2005 04:03 PM To Brett Gavagni/West Palm Beach/IBM@IBMUS, cc Subject RE: [Speechsc] Personal-Grammar-URI clarification I am not sure what you mean by its relationship to Content-Id. To me Personal-Grammar-URI is just like anyother grammar that has a list of items. Except that it is constructed by the user adding individual phrases to that one-of list during enrollment. Once enrolled, the usage of that grammar should be no different from any other grammar. This could be a HTTP URI in which case the MRCP server uses HTTP GET/PUT to modify that grammar during enrollment. So to answer your question, the MRCP server is not expected to store this personal grammar, but would be create/modified at the URI specified by the personal grammar URI. Sarvi -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni Sent: Wednesday, August 10, 2005 11:43 AM To: speechsc@ietf.org Subject: Re: [Speechsc] Personal-Grammar-URI clarification Bump Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com Brett Gavagni/West Palm Beach/IBM@IBMUS Sent by: speechsc-bounces@ietf.org 07/26/2005 11:28 AM To speechsc@ietf.org cc Subject [Speechsc] Personal-Grammar-URI clarification Hi, The wording throughout the current draft specification is a bit confusing w.r.t "Personal-Grammar-URI". Is the expectation that the "Personal-Grammar-URI" value is merely a client specified handle to an external grammar in lieu of using a "Content-Id" value? Is the expectation that the server persistently store these references and the backing grammars, and when and how would the release of these references occur? Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Mon Aug 22 13:25:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7G3B-000647-Qr; Mon, 22 Aug 2005 13:25:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7G3A-00063p-OF for speechsc@megatron.ietf.org; Mon, 22 Aug 2005 13:25:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29584 for ; Mon, 22 Aug 2005 13:25:29 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Gdl-0008G4-Ft for speechsc@ietf.org; Mon, 22 Aug 2005 14:03:22 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 22 Aug 2005 10:25:19 -0700 X-IronPort-AV: i="3.96,131,1122879600"; d="scan'208"; a="206729950:sNHT29774894" Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j7MHPG2i019198; Mon, 22 Aug 2005 10:25:17 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property Date: Mon, 22 Aug 2005 10:25:17 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C2C4046@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property Thread-Index: AcWnKcmBJwbbicY9R0G6MrYIQJBfRAAFILqQ From: "Shanmugham, Saravanan" To: "Brett Gavagni" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Status in Issue Tracker. --------------------------- Addressed this by changing START-OF-SPEECH to START-OF-INPUT. Added an Input-Type header to all input processing resources, with values "speech" and "dtmf" Add text to explain that what constitutes a barge-in event based on the resource type and the grammars that are active. START-OF-INPUT event is generated with this barge-in condition is met. Sarvi -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni Sent: Monday, August 22, 2005 7:53 AM To: speechsc@ietf.org Subject: [Speechsc] MRCPv2 requirements for VoiceXML=20 "inputmodes" property =20 Hi, =20 What's the status of this request that was made a few=20 months ago, as it doesn't appear to have been addressed in=20 the -07 draft? =20 Here's the thread on the topic: http://www1.ietf.org/mail-archive/web/speechsc/current/msg0 1234.html =20 Thanks, =20 Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Mon Aug 22 17:53:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7KEt-00075Y-S6; Mon, 22 Aug 2005 17:53:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7KEr-00074U-JY for speechsc@megatron.ietf.org; Mon, 22 Aug 2005 17:53:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22780 for ; Mon, 22 Aug 2005 17:53:48 -0400 (EDT) Received: from e3.ny.us.ibm.com ([32.97.182.143]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7KEm-0002Ns-SD for speechsc@ietf.org; Mon, 22 Aug 2005 17:53:51 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j7MLrWCk001829 for ; Mon, 22 Aug 2005 17:53:35 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7MLreh5348960 for ; Mon, 22 Aug 2005 15:53:40 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j7MLrVO3023697 for ; Mon, 22 Aug 2005 15:53:31 -0600 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j7MLrVvC023694 for ; Mon, 22 Aug 2005 15:53:31 -0600 In-Reply-To: <03772D1EC8DE624A863058C75874A75C2C4046@vtg-um-e2k6.sj21ad.cisco.com> To: "Shanmugham, Saravanan" MIME-Version: 1.0 Subject: RE: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Brett Gavagni Date: Mon, 22 Aug 2005 17:53:40 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.5.4|March 27, 2005) at 08/22/2005 15:53:42, Serialize complete at 08/22/2005 15:53:43, Serialize by Router on D03NM119/03/M/IBM(Release 6.5.4|March 27, 2005) at 08/22/2005 15:53:43 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org It seems a bit inefficient for a VoiceXML platform utilizing MRCP to rely on the START-OF-INPUT to determine if the identified "Input-Type" is enabled in the current VoiceXML application execution context. I would suggest that a MRCP client be able to specify the input mode during the RECOGNIZE request. Additionally, including the mode that MRCP server's grammar processor interpreted for each DEFINE-GRAMMAR request would assist the MRCP client with enabling the ideal set of grammars. Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com "Shanmugham, Saravanan" 08/22/2005 01:25 PM To Brett Gavagni/West Palm Beach/IBM@IBMUS, cc Subject RE: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property Status in Issue Tracker. --------------------------- Addressed this by changing START-OF-SPEECH to START-OF-INPUT. Added an Input-Type header to all input processing resources, with values "speech" and "dtmf" Add text to explain that what constitutes a barge-in event based on the resource type and the grammars that are active. START-OF-INPUT event is generated with this barge-in condition is met. Sarvi -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni Sent: Monday, August 22, 2005 7:53 AM To: speechsc@ietf.org Subject: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property Hi, What's the status of this request that was made a few months ago, as it doesn't appear to have been addressed in the -07 draft? Here's the thread on the topic: http://www1.ietf.org/mail-archive/web/speechsc/current/msg0 1234.html Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue Aug 23 01:45:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7RbY-0006Gu-KS; Tue, 23 Aug 2005 01:45:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7RbW-0006GH-Dx for speechsc@megatron.ietf.org; Tue, 23 Aug 2005 01:45:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01407 for ; Tue, 23 Aug 2005 01:45:45 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7RbM-0008SV-RI for speechsc@ietf.org; Tue, 23 Aug 2005 01:45:37 -0400 Received: from daburkewxp (dsl-34-34.dsl.netsource.ie [213.79.34.34]) by mail.voxpilot.com (Postfix) with ESMTP id 68CFF214042; Tue, 23 Aug 2005 05:45:23 +0000 (GMT) Message-ID: <016801c5a7a5$db4064c0$0a01a8c0@db01.voxpilot.com> From: "Dave Burke" To: "Shanmugham, Saravanan" , "Brett Gavagni" , References: <03772D1EC8DE624A863058C75874A75C2C4046@vtg-um-e2k6.sj21ad.cisco.com> Subject: Re: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property Date: Tue, 23 Aug 2005 06:45:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Sarvi, The changes below look mostly fine to me with the bug noted (point C in http://www1.ietf.org/mail-archive/web/speechsc/current/msg01485.html). One concern I do have with it is that -07 says about the speechrecog resource: "This resource generates barge-in events for speech. By analyzing the grammars that are activated by the RECOGNIZE method, it also figures out if a barge-in should occur for DTMF or not." whereas I thought it ought to say (based on our discussions): "This resource generates barge-in events for speech and/or DTMF. By analyzing the grammar types that are activated by the RECOGNIZE method, it determines if a barge-in should occur for speech and/or DTMF" The concern I have with the current wording is that during a call, it is common to go from speech+dtmf reco to dtmf-only reco and then back to speech+dtmf. With current wording, one would need to perform a REINVITE to change from a speechrecog to a dtmfrecog. To revert to speech+dtmf, another REINVITEs is needed. So 2 REINVITEs (=6 SIP messages) would be needed to handle the common use-case for DTMF-only fallback. Dave ----- Original Message ----- From: "Shanmugham, Saravanan" To: "Brett Gavagni" ; Sent: Monday, August 22, 2005 6:25 PM Subject: RE: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property Status in Issue Tracker. --------------------------- Addressed this by changing START-OF-SPEECH to START-OF-INPUT. Added an Input-Type header to all input processing resources, with values "speech" and "dtmf" Add text to explain that what constitutes a barge-in event based on the resource type and the grammars that are active. START-OF-INPUT event is generated with this barge-in condition is met. Sarvi -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni Sent: Monday, August 22, 2005 7:53 AM To: speechsc@ietf.org Subject: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property Hi, What's the status of this request that was made a few months ago, as it doesn't appear to have been addressed in the -07 draft? Here's the thread on the topic: http://www1.ietf.org/mail-archive/web/speechsc/current/msg0 1234.html Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue Aug 23 02:20:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7S8w-0004Ok-Cd; Tue, 23 Aug 2005 02:20:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7S8s-0004NY-Ur for speechsc@megatron.ietf.org; Tue, 23 Aug 2005 02:20:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15641 for ; Tue, 23 Aug 2005 02:20:13 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7S8w-0000pY-IT for speechsc@ietf.org; Tue, 23 Aug 2005 02:20:19 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 22 Aug 2005 23:20:05 -0700 Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j7N6K22i024327; Mon, 22 Aug 2005 23:20:02 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property Date: Mon, 22 Aug 2005 23:17:17 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C2C4127@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property Thread-Index: AcWnpjwzgCzYZoZlSp+QcIN1yoCyWwAA/1Jg From: "Shanmugham, Saravanan" To: "Dave Burke" , "Brett Gavagni" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org The difference, I see between the 2 is or Vs and/or. I can certainly make that change. But I don't understand your SIP INVITE deal. This choice of dtmf and/or speech for barge-input is based on a per RECOGNIZE method.=20 That is where we activate recognition and specify a list of grammars to activate. I was thinking that's where this choice would be made based on the list of grammars being activated.=20 I don't see any SIP re-INVITES happenning in this case. Am I missing something. Sarvi=20 =20 -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke Sent: Monday, August 22, 2005 10:45 PM To: Shanmugham, Saravanan; Brett Gavagni; speechsc@ietf.org Subject: Re: [Speechsc] MRCPv2 requirements for VoiceXML=20 "inputmodes" property =20 Sarvi, =20 The changes below look mostly fine to me with the bug=20 noted (point C in=20 http://www1.ietf.org/mail-archive/web/speechsc/current/msg0 1485.html). =20 One concern I do have with it is that -07 says about the=20 speechrecog resource: =20 "This resource generates barge-in events for speech. By analyzing the grammars that are activated by the RECOGNIZE method, it also figures out if a barge-in=20 should occur for DTMF or not." =20 whereas I thought it ought to say (based on our discussions): =20 "This resource generates barge-in events for speech and/or DTMF. By analyzing the grammar types=20 that are activated by the RECOGNIZE method, it determines if a barge-in=20 should occur for speech and/or DTMF" =20 The concern I have with the current wording is that during=20 a call, it is common to go from speech+dtmf reco to=20 dtmf-only reco and then back to speech+dtmf. With current wording, one would need to=20 perform a REINVITE to change from a speechrecog to a dtmfrecog. To revert to=20 speech+dtmf, another REINVITEs is needed. So 2 REINVITEs=20 (=3D6 SIP messages) would be needed to handle the common=20 use-case for DTMF-only fallback. =20 Dave =20 ----- Original Message ----- From: "Shanmugham, Saravanan" To: "Brett Gavagni" ; Sent: Monday, August 22, 2005 6:25 PM Subject: RE: [Speechsc] MRCPv2 requirements for VoiceXML=20 "inputmodes"=20 property =20 =20 Status in Issue Tracker. --------------------------- Addressed this by changing START-OF-SPEECH to START-OF-INPUT. Added an Input-Type header to all input processing resources, with values "speech" and "dtmf" Add text to explain that what constitutes a barge-in event=20 based on the resource type and the grammars that are active. START-OF-INPUT event is generated with this barge-in condition is met. =20 =20 Sarvi =20 =20 =20 -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni Sent: Monday, August 22, 2005 7:53 AM To: speechsc@ietf.org Subject: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property =20 Hi, =20 What's the status of this request that was made a few months ago, as it doesn't appear to have been addressed in the -07 draft? =20 Here's the thread on the topic: http://www1.ietf.org/mail-archive/web/speechsc/current/msg0 1234.html =20 Thanks, =20 Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue Aug 23 03:02:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7SnY-0003cJ-8b; Tue, 23 Aug 2005 03:02:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7SnT-0003c0-Lt for speechsc@megatron.ietf.org; Tue, 23 Aug 2005 03:02:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17811 for ; Tue, 23 Aug 2005 03:02:10 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7SnV-0001wB-PV for speechsc@ietf.org; Tue, 23 Aug 2005 03:02:15 -0400 Received: from daburkewxp (dsl-34-34.dsl.netsource.ie [213.79.34.34]) by mail.voxpilot.com (Postfix) with ESMTP id 09F13214042; Tue, 23 Aug 2005 07:01:58 +0000 (GMT) Message-ID: <01e101c5a7b0$8dd9c8b0$0a01a8c0@db01.voxpilot.com> From: "Dave Burke" To: "Shanmugham, Saravanan" , "Brett Gavagni" , References: <03772D1EC8DE624A863058C75874A75C2C4127@vtg-um-e2k6.sj21ad.cisco.com> Subject: Re: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property Date: Tue, 23 Aug 2005 08:01:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org In the -07 version, the wording implies that the speechrecog will always barge-in on speech input regardless of whether a speech grammar was activated in the RECOGNIZE. So imagine a client has connected to a speechrecog resource. At a certain point, it wants to perform a DTMF-only recognition (because it's noisy). If it performs a RECOGNIZE and activates just a DTMF grammar, the -07 implies that the speechrecog will still barge-in on speech input (in this case the noise). The only way to perform a DTMF-only recognition with the -07 version is to change the resource type from a speechrecog to a dtmfrecog by performing a re-INVITE (altering the SDP by changing the a=resource:speechrecog to a=resource:dtmfrecog). If we change the wording as suggested below, then it will work with needing a re-INVITE. Dave ----- Original Message ----- From: "Shanmugham, Saravanan" To: "Dave Burke" ; "Brett Gavagni" ; Sent: Tuesday, August 23, 2005 7:17 AM Subject: RE: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property The difference, I see between the 2 is or Vs and/or. I can certainly make that change. But I don't understand your SIP INVITE deal. This choice of dtmf and/or speech for barge-input is based on a per RECOGNIZE method. That is where we activate recognition and specify a list of grammars to activate. I was thinking that's where this choice would be made based on the list of grammars being activated. I don't see any SIP re-INVITES happenning in this case. Am I missing something. Sarvi -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke Sent: Monday, August 22, 2005 10:45 PM To: Shanmugham, Saravanan; Brett Gavagni; speechsc@ietf.org Subject: Re: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property Sarvi, The changes below look mostly fine to me with the bug noted (point C in http://www1.ietf.org/mail-archive/web/speechsc/current/msg0 1485.html). One concern I do have with it is that -07 says about the speechrecog resource: "This resource generates barge-in events for speech. By analyzing the grammars that are activated by the RECOGNIZE method, it also figures out if a barge-in should occur for DTMF or not." whereas I thought it ought to say (based on our discussions): "This resource generates barge-in events for speech and/or DTMF. By analyzing the grammar types that are activated by the RECOGNIZE method, it determines if a barge-in should occur for speech and/or DTMF" The concern I have with the current wording is that during a call, it is common to go from speech+dtmf reco to dtmf-only reco and then back to speech+dtmf. With current wording, one would need to perform a REINVITE to change from a speechrecog to a dtmfrecog. To revert to speech+dtmf, another REINVITEs is needed. So 2 REINVITEs (=6 SIP messages) would be needed to handle the common use-case for DTMF-only fallback. Dave ----- Original Message ----- From: "Shanmugham, Saravanan" To: "Brett Gavagni" ; Sent: Monday, August 22, 2005 6:25 PM Subject: RE: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property Status in Issue Tracker. --------------------------- Addressed this by changing START-OF-SPEECH to START-OF-INPUT. Added an Input-Type header to all input processing resources, with values "speech" and "dtmf" Add text to explain that what constitutes a barge-in event based on the resource type and the grammars that are active. START-OF-INPUT event is generated with this barge-in condition is met. Sarvi -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni Sent: Monday, August 22, 2005 7:53 AM To: speechsc@ietf.org Subject: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property Hi, What's the status of this request that was made a few months ago, as it doesn't appear to have been addressed in the -07 draft? Here's the thread on the topic: http://www1.ietf.org/mail-archive/web/speechsc/current/msg0 1234.html Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue Aug 23 10:34:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Zqt-0003V3-Bn; Tue, 23 Aug 2005 10:34:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Zqr-0003To-Oc for speechsc@megatron.ietf.org; Tue, 23 Aug 2005 10:34:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07879 for ; Tue, 23 Aug 2005 10:34:07 -0400 (EDT) Received: from mail.voicegenie.com ([205.150.90.87] helo=voicegenie.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Zqy-0006NP-MX for speechsc@ietf.org; Tue, 23 Aug 2005 10:34:17 -0400 Received: from [205.150.90.65] (parrot.voicegenie.com [205.150.90.65]) by voicegenie.com (8.11.6+Sun/8.9.3) with ESMTP id j7NEXnP28539 for ; Tue, 23 Aug 2005 10:33:49 -0400 (EDT) Message-ID: <430B33CD.3000807@voicegenie.com> Date: Tue, 23 Aug 2005 10:33:49 -0400 From: Andrew Wahbe Organization: VoiceGenie Technologies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: speechsc@ietf.org Content-Type: multipart/mixed; boundary="------------070502070204070209060403" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [Speechsc] Recognition Completion-Cause Codes 003 and 008 revisited X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --------------070502070204070209060403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit A few weeks ago, there was an extensive discussion about the recognition completion-cause codes for cases where recognition-timers fire. There seemed to be two codes, 003 and 008, that meant the same thing -- the recognition was aborted due to the recognition-timer firing. This case maps to the maxspeechtimeout event in VoiceXML. A lot of hypothesizing was done to try and figure out what the difference between the codes was. After some discussion it seems we ended up with no codes that map to maxspeechtimeout in VoiceXML (i.e. the recognition was aborted because of recognition-timeout and there is no match). I think things would be set right if 003 was changed from: | 003 | recognition-timeout | RECOGNIZE in hotword mode | | | | completed without a match due to | | | | a recognition-timeout | to: | 003 | recognition-timeout | RECOGNIZE completed without a | | | | match due to a | | | | recognition-timeout | I am not sure why a special code is needed for this timer firing in hotword mode. Am I missing something? Andrew Wahbe VoiceGenie Technologies --------------070502070204070209060403 Content-Type: text/x-vcard; charset=utf-8; name="awahbe.vcf" Content-Disposition: attachment; filename="awahbe.vcf" Content-Transfer-Encoding: 7bit begin:vcard fn:Andrew Wahbe n:Wahbe;Andrew org:VoiceGenie Technologies INC.;Multimodal and Development Tools adr:8th Floor;;1120 Finch Avenue W.;Toronto;ON;M3J 3H7;Canada email;internet:awahbe@voicegenie.com title:Technical Manager tel;work:(416) 736-0905 ext. 258 tel;fax:(416) 736-1551 x-mozilla-html:TRUE url:http://www.voicegenie.com version:2.1 end:vcard --------------070502070204070209060403 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --------------070502070204070209060403-- From speechsc-bounces@ietf.org Tue Aug 23 11:21:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7aaO-0004d7-UC; Tue, 23 Aug 2005 11:21:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7aaH-0004cz-EH for speechsc@megatron.ietf.org; Tue, 23 Aug 2005 11:21:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09715 for ; Tue, 23 Aug 2005 11:21:03 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7aaO-0007ca-Ip for speechsc@ietf.org; Tue, 23 Aug 2005 11:21:14 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 23 Aug 2005 08:20:54 -0700 X-IronPort-AV: i="3.96,135,1122879600"; d="scan'208"; a="334893904:sNHT33776872" Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7NFKn0J027338; Tue, 23 Aug 2005 08:20:50 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property Date: Tue, 23 Aug 2005 08:18:27 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C2C413C@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property Thread-Index: AcWnsJl0uTe7tL3oRSyAMbS/F7E5rAARLBBg From: "Shanmugham, Saravanan" To: "Dave Burke" , "Brett Gavagni" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org The speech syntheisizer barges-in when the it receives the BARGEIN-OCCURRED method from the client, or if the recognizer on the same session generated a START-OF-INPUTE event, in the optimized barge-in case. The question though, is when does the START-OF-INPUT event get generated. And based on the current wording , the recognizer should be smart enough to generate only one START-OF-INPUT event based on the grammars that are active for that RECOGNIZE method. Sarvi=20 -----Original Message----- From: Dave Burke [mailto:david.burke@voxpilot.com]=20 Sent: Tuesday, August 23, 2005 12:02 AM To: Shanmugham, Saravanan; Brett Gavagni; speechsc@ietf.org Subject: Re: [Speechsc] MRCPv2 requirements for VoiceXML=20 "inputmodes" property =20 In the -07 version, the wording implies that the=20 speechrecog will always barge-in on speech input=20 regardless of whether a speech grammar was activated in=20 the RECOGNIZE. =20 So imagine a client has connected to a speechrecog=20 resource. At a certain point, it wants to perform a=20 DTMF-only recognition (because it's noisy). If it performs=20 a RECOGNIZE and activates just a DTMF grammar, the -07=20 implies that the speechrecog will still barge-in on speech=20 input (in this case the noise). The only way to perform a=20 DTMF-only recognition with the -07 version is to change=20 the resource type from a speechrecog to a dtmfrecog by=20 performing a re-INVITE (altering the SDP by changing the=20 a=3Dresource:speechrecog to a=3Dresource:dtmfrecog). =20 If we change the wording as suggested below, then it will=20 work with needing a re-INVITE. =20 Dave =20 ----- Original Message ----- From: "Shanmugham, Saravanan" To: "Dave Burke" ; "Brett Gavagni"=20 ; Sent: Tuesday, August 23, 2005 7:17 AM Subject: RE: [Speechsc] MRCPv2 requirements for VoiceXML=20 "inputmodes"=20 property =20 =20 The difference, I see between the 2 is or Vs and/or. I can=20 certainly make that change. But I don't understand your SIP INVITE deal. =20 This choice of dtmf and/or speech for barge-input is based on a per RECOGNIZE method. That is where we activate recognition and specify a list=20 of grammars to activate. I was thinking that's where this choice would be=20 made based on the list of grammars being activated. =20 I don't see any SIP re-INVITES happenning in this case. Am=20 I missing something. =20 Sarvi =20 =20 -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke Sent: Monday, August 22, 2005 10:45 PM To: Shanmugham, Saravanan; Brett Gavagni; speechsc@ietf.org Subject: Re: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property =20 Sarvi, =20 The changes below look mostly fine to me with the bug noted (point C in http://www1.ietf.org/mail-archive/web/speechsc/current/msg0 1485.html). =20 One concern I do have with it is that -07 says about the speechrecog resource: =20 "This resource generates barge-in events for speech. By analyzing the grammars that are=20 activated by the RECOGNIZE method, it also figures out if a barge-in should occur for DTMF or not." =20 whereas I thought it ought to say (based on our discussions): =20 "This resource generates barge-in events for speech and/or DTMF. By analyzing the grammar types that are activated by the RECOGNIZE method, it determines if a barge-in should occur for speech and/or DTMF" =20 The concern I have with the current wording is that during a call, it is common to go from speech+dtmf reco to dtmf-only reco and then back to speech+dtmf. With current wording, one would need to perform a REINVITE to change from a speechrecog to a dtmfrecog. To revert to speech+dtmf, another REINVITEs is needed. So 2 REINVITEs (=3D6 SIP messages) would be needed to handle the common use-case for DTMF-only fallback. =20 Dave =20 ----- Original Message ----- From: "Shanmugham, Saravanan" To: "Brett Gavagni" ; Sent: Monday, August 22, 2005 6:25 PM Subject: RE: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property =20 =20 Status in Issue Tracker. --------------------------- Addressed this by changing START-OF-SPEECH to START-OF-INPUT. Added an Input-Type header to all input processing=20 resources, with values "speech" and "dtmf" Add text to explain that what constitutes a barge-in event based on the resource type and the grammars that are active. =20 START-OF-INPUT event is generated with this barge-in condition is met. =20 =20 Sarvi =20 =20 =20 -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of=20 Brett Gavagni Sent: Monday, August 22, 2005 7:53 AM To: speechsc@ietf.org Subject: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property =20 Hi, =20 What's the status of this request that was made a few months ago, as it doesn't appear to have been=20 addressed in the -07 draft? =20 Here's the thread on the topic: =20 http://www1.ietf.org/mail-archive/web/speechsc/current/msg0 1234.html =20 Thanks, =20 Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue Aug 23 11:57:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7b9a-0004Tp-32; Tue, 23 Aug 2005 11:57:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7b9X-0004Tf-E1 for speechsc@megatron.ietf.org; Tue, 23 Aug 2005 11:57:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11881 for ; Tue, 23 Aug 2005 11:57:28 -0400 (EDT) Received: from pb-exchcon2.scansoft.com ([199.4.160.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7b9e-0000S6-RA for speechsc@ietf.org; Tue, 23 Aug 2005 11:57:40 -0400 Received: by pb-exchcon2.pb.scansoft.com with Internet Mail Service (5.5.2658.27) id ; Tue, 23 Aug 2005 11:57:11 -0400 Message-ID: From: "Reifenrath, Klaus" To: "'sarvi@cisco.com'" , "'dburnett@vocalocity.net'" Date: Tue, 23 Aug 2005 11:41:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.27) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: "'speechsc@ietf.org'" Subject: [Speechsc] Problem with DTMF type-ahead X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0524442089==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0524442089== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A7F9.12D2F47C" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5A7F9.12D2F47C Content-Type: text/plain The MRCP and MRCPv2 specifications define how DTMF input should be handled: DTMF input is collected after the RECOGNIZE request is received until a term-char or timeout is reached. Then a result or no-match is returned based on any active DTMF grammars. The problem is there can be a significant amount of time between when one result is processed by the application and the next grammar is activated. During that time any DTMF input received will be lost. Such DTMF type-ahead is common for frequent users of IVR systems, and buffering that type ahead is required by VoiceXML 2.0 (see section 4.1.8). Can this requirement of VoiceXML be implemented using MRCP (assuming that the media source CANNOT buffer DTMF)? If so, how is it done? Thanks, Klaus ------_=_NextPart_001_01C5A7F9.12D2F47C Content-Type: text/html Content-Transfer-Encoding: quoted-printable Problem with DTMF type-ahead

The MRCP and MRCPv2 specifications = define how DTMF input should be handled: DTMF input is collected after = the RECOGNIZE request is received until a term-char or timeout is = reached. Then a result or no-match is returned based on any active DTMF = grammars. The problem is there can be a significant amount of time = between when one result is processed by the application and the next = grammar is activated. During that time any DTMF input received will be = lost. Such DTMF type-ahead is common for frequent users of IVR systems, = and buffering that type ahead is required by VoiceXML 2.0 (see section = 4.1.8). Can this requirement of VoiceXML be implemented using MRCP = (assuming that the media source CANNOT buffer DTMF)? If so, how is it = done?

Thanks,
Klaus

------_=_NextPart_001_01C5A7F9.12D2F47C-- --===============0524442089== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============0524442089==-- From speechsc-bounces@ietf.org Tue Aug 23 12:20:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7bVW-0002OS-5Q; Tue, 23 Aug 2005 12:20:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7bVS-0002OE-1P for speechsc@megatron.ietf.org; Tue, 23 Aug 2005 12:20:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13012 for ; Tue, 23 Aug 2005 12:20:07 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7bVa-00017k-69 for speechsc@ietf.org; Tue, 23 Aug 2005 12:20:19 -0400 Received: from daburkewxp (s143-017.psd.vodafone.ie [213.233.143.17]) by mail.voxpilot.com (Postfix) with ESMTP id 10A27214041; Tue, 23 Aug 2005 16:19:49 +0000 (GMT) Message-ID: <040501c5a7fe$7c926d70$0a01a8c0@db01.voxpilot.com> From: "Dave Burke" To: "Shanmugham, Saravanan" , "Brett Gavagni" , References: <03772D1EC8DE624A863058C75874A75C2C413C@vtg-um-e2k6.sj21ad.cisco.com> Subject: Re: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property Date: Tue, 23 Aug 2005 17:19:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Right - I was talking about the optimised case. Looks like we both agree on the mechanism. My problem is only with the wording "This resource generates barge-in events for speech" and "it also figures out if a barge-in should occur for DTMF". This reads to me that the speechrecog *always* generates a START-OF-INPUT for any speech/noise heard regardless of what grammar types were activated in the RECOGNIZE. The small text change suggested below removes the ambiguity. Hope I'm being clear. Thanks, Dave ----- Original Message ----- From: "Shanmugham, Saravanan" To: "Dave Burke" ; "Brett Gavagni" ; Sent: Tuesday, August 23, 2005 4:18 PM Subject: RE: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property The speech syntheisizer barges-in when the it receives the BARGEIN-OCCURRED method from the client, or if the recognizer on the same session generated a START-OF-INPUTE event, in the optimized barge-in case. The question though, is when does the START-OF-INPUT event get generated. And based on the current wording , the recognizer should be smart enough to generate only one START-OF-INPUT event based on the grammars that are active for that RECOGNIZE method. Sarvi -----Original Message----- From: Dave Burke [mailto:david.burke@voxpilot.com] Sent: Tuesday, August 23, 2005 12:02 AM To: Shanmugham, Saravanan; Brett Gavagni; speechsc@ietf.org Subject: Re: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property In the -07 version, the wording implies that the speechrecog will always barge-in on speech input regardless of whether a speech grammar was activated in the RECOGNIZE. So imagine a client has connected to a speechrecog resource. At a certain point, it wants to perform a DTMF-only recognition (because it's noisy). If it performs a RECOGNIZE and activates just a DTMF grammar, the -07 implies that the speechrecog will still barge-in on speech input (in this case the noise). The only way to perform a DTMF-only recognition with the -07 version is to change the resource type from a speechrecog to a dtmfrecog by performing a re-INVITE (altering the SDP by changing the a=resource:speechrecog to a=resource:dtmfrecog). If we change the wording as suggested below, then it will work with needing a re-INVITE. Dave ----- Original Message ----- From: "Shanmugham, Saravanan" To: "Dave Burke" ; "Brett Gavagni" ; Sent: Tuesday, August 23, 2005 7:17 AM Subject: RE: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property The difference, I see between the 2 is or Vs and/or. I can certainly make that change. But I don't understand your SIP INVITE deal. This choice of dtmf and/or speech for barge-input is based on a per RECOGNIZE method. That is where we activate recognition and specify a list of grammars to activate. I was thinking that's where this choice would be made based on the list of grammars being activated. I don't see any SIP re-INVITES happenning in this case. Am I missing something. Sarvi -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke Sent: Monday, August 22, 2005 10:45 PM To: Shanmugham, Saravanan; Brett Gavagni; speechsc@ietf.org Subject: Re: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property Sarvi, The changes below look mostly fine to me with the bug noted (point C in http://www1.ietf.org/mail-archive/web/speechsc/current/msg0 1485.html). One concern I do have with it is that -07 says about the speechrecog resource: "This resource generates barge-in events for speech. By analyzing the grammars that are activated by the RECOGNIZE method, it also figures out if a barge-in should occur for DTMF or not." whereas I thought it ought to say (based on our discussions): "This resource generates barge-in events for speech and/or DTMF. By analyzing the grammar types that are activated by the RECOGNIZE method, it determines if a barge-in should occur for speech and/or DTMF" The concern I have with the current wording is that during a call, it is common to go from speech+dtmf reco to dtmf-only reco and then back to speech+dtmf. With current wording, one would need to perform a REINVITE to change from a speechrecog to a dtmfrecog. To revert to speech+dtmf, another REINVITEs is needed. So 2 REINVITEs (=6 SIP messages) would be needed to handle the common use-case for DTMF-only fallback. Dave ----- Original Message ----- From: "Shanmugham, Saravanan" To: "Brett Gavagni" ; Sent: Monday, August 22, 2005 6:25 PM Subject: RE: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property Status in Issue Tracker. --------------------------- Addressed this by changing START-OF-SPEECH to START-OF-INPUT. Added an Input-Type header to all input processing resources, with values "speech" and "dtmf" Add text to explain that what constitutes a barge-in event based on the resource type and the grammars that are active. START-OF-INPUT event is generated with this barge-in condition is met. Sarvi -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni Sent: Monday, August 22, 2005 7:53 AM To: speechsc@ietf.org Subject: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property Hi, What's the status of this request that was made a few months ago, as it doesn't appear to have been addressed in the -07 draft? Here's the thread on the topic: http://www1.ietf.org/mail-archive/web/speechsc/current/msg0 1234.html Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue Aug 23 12:39:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7boA-0006LW-7P; Tue, 23 Aug 2005 12:39:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7bo7-0006KE-Iz for speechsc@megatron.ietf.org; Tue, 23 Aug 2005 12:39:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13851 for ; Tue, 23 Aug 2005 12:39:24 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7boG-0001hC-IE for speechsc@ietf.org; Tue, 23 Aug 2005 12:39:37 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 23 Aug 2005 09:39:18 -0700 Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j7NGcw32011295; Tue, 23 Aug 2005 09:39:16 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property Date: Tue, 23 Aug 2005 09:39:14 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C2C4150@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property Thread-Index: AcWn/sUzQH2+HqPdQXSpU/dtXLpcXQAAlKiw From: "Shanmugham, Saravanan" To: "Dave Burke" , "Brett Gavagni" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org If we agree on the concept I can clarify the text. Sarvi=20 -----Original Message----- From: Dave Burke [mailto:david.burke@voxpilot.com]=20 Sent: Tuesday, August 23, 2005 9:20 AM To: Shanmugham, Saravanan; Brett Gavagni; speechsc@ietf.org Subject: Re: [Speechsc] MRCPv2 requirements for VoiceXML=20 "inputmodes" property =20 Right - I was talking about the optimised case. Looks like=20 we both agree on the mechanism. My problem is only with=20 the wording "This resource generates barge-in events for=20 speech" and "it also figures out if a barge-in should=20 occur for DTMF". =20 This reads to me that the speechrecog *always* generates a=20 START-OF-INPUT for any speech/noise heard regardless of=20 what grammar types were activated in the RECOGNIZE. The=20 small text change suggested below removes the ambiguity.=20 Hope I'm being clear. =20 Thanks, =20 Dave =20 ----- Original Message ----- From: "Shanmugham, Saravanan" To: "Dave Burke" ; "Brett Gavagni"=20 ; Sent: Tuesday, August 23, 2005 4:18 PM Subject: RE: [Speechsc] MRCPv2 requirements for VoiceXML=20 "inputmodes"=20 property =20 =20 The speech syntheisizer barges-in when the it receives the BARGEIN-OCCURRED method from the client, or if the=20 recognizer on the same session generated a START-OF-INPUTE event, in the optimized barge-in case. =20 The question though, is when does the START-OF-INPUT event get generated. And based on the current wording , the=20 recognizer should be smart enough to generate only one START-OF-INPUT event based on the grammars that are active for that RECOGNIZE method. =20 Sarvi =20 -----Original Message----- From: Dave Burke [mailto:david.burke@voxpilot.com] Sent: Tuesday, August 23, 2005 12:02 AM To: Shanmugham, Saravanan; Brett Gavagni; speechsc@ietf.org Subject: Re: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property =20 In the -07 version, the wording implies that the speechrecog will always barge-in on speech input regardless of whether a speech grammar was activated in the RECOGNIZE. =20 So imagine a client has connected to a speechrecog resource. At a certain point, it wants to perform a DTMF-only recognition (because it's noisy). If it performs a RECOGNIZE and activates just a DTMF grammar, the -07 implies that the speechrecog will still barge-in on speech input (in this case the noise). The only way to perform a DTMF-only recognition with the -07 version is to change the resource type from a speechrecog to a dtmfrecog by performing a re-INVITE (altering the SDP by changing the a=3Dresource:speechrecog to a=3Dresource:dtmfrecog). =20 If we change the wording as suggested below, then it will work with needing a re-INVITE. =20 Dave =20 ----- Original Message ----- From: "Shanmugham, Saravanan" To: "Dave Burke" ; "Brett Gavagni" ; Sent: Tuesday, August 23, 2005 7:17 AM Subject: RE: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property =20 =20 The difference, I see between the 2 is or Vs and/or. I can certainly make that change. But I don't understand your SIP INVITE deal. =20 This choice of dtmf and/or speech for barge-input is=20 based on a per RECOGNIZE method. That is where we activate recognition and specify a list of grammars to activate. I was thinking that's where this choice would be made based on the list of grammars being activated. =20 I don't see any SIP re-INVITES happenning in this case. Am I missing something. =20 Sarvi =20 =20 -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of=20 Dave Burke Sent: Monday, August 22, 2005 10:45 PM To: Shanmugham, Saravanan; Brett Gavagni;=20 speechsc@ietf.org Subject: Re: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property =20 Sarvi, =20 The changes below look mostly fine to me with the bug noted (point C in =20 http://www1.ietf.org/mail-archive/web/speechsc/current/msg0 1485.html). =20 One concern I do have with it is that -07 says about the speechrecog resource: =20 "This resource generates barge-in events for speech. By analyzing the grammars that are activated by the RECOGNIZE method, it also figures out if a barge-in should occur for DTMF or not." =20 whereas I thought it ought to say (based on our=20 discussions): =20 "This resource generates barge-in events for speech and/or DTMF. By analyzing the grammar types that are activated by the RECOGNIZE method, it determines if a barge-in should occur for speech and/or DTMF" =20 The concern I have with the current wording is=20 that during a call, it is common to go from speech+dtmf reco to dtmf-only reco and then back to speech+dtmf. With current wording, one would need to perform a REINVITE to change from a speechrecog to a dtmfrecog. To revert to speech+dtmf, another REINVITEs is needed. So 2 REINVITEs (=3D6 SIP messages) would be needed to handle the common use-case for DTMF-only fallback. =20 Dave =20 ----- Original Message ----- From: "Shanmugham, Saravanan" To: "Brett Gavagni" ;=20 Sent: Monday, August 22, 2005 6:25 PM Subject: RE: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property =20 =20 Status in Issue Tracker. --------------------------- Addressed this by changing START-OF-SPEECH to=20 START-OF-INPUT. Added an Input-Type header to all input processing resources, with values "speech" and "dtmf" Add text to explain that what constitutes a=20 barge-in event based on the resource type and the grammars that are active. START-OF-INPUT event is generated with this barge-in condition is met. =20 =20 Sarvi =20 =20 =20 -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni Sent: Monday, August 22, 2005 7:53 AM To: speechsc@ietf.org Subject: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property =20 Hi, =20 What's the status of this request that was=20 made a few months ago, as it doesn't appear to have been addressed in the -07 draft? =20 Here's the thread on the topic: =20 http://www1.ietf.org/mail-archive/web/speechsc/current/msg0 1234.html =20 Thanks, =20 Brett Gavagni WebSphere Voice Server Development =20 http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue Aug 23 15:29:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7eSy-0007c8-27; Tue, 23 Aug 2005 15:29:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7eSw-0007c3-2X for speechsc@megatron.ietf.org; Tue, 23 Aug 2005 15:29:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25891 for ; Tue, 23 Aug 2005 15:29:44 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7eSz-0007X1-UH for speechsc@ietf.org; Tue, 23 Aug 2005 15:29:56 -0400 Received: from daburkewxp (unknown [213.233.153.171]) by mail.voxpilot.com (Postfix) with ESMTP id 49B4B214041; Tue, 23 Aug 2005 19:29:26 +0000 (GMT) Message-ID: <049601c5a818$fa241f80$0a01a8c0@db01.voxpilot.com> From: "Dave Burke" To: "Reifenrath, Klaus" , , References: Subject: Re: [Speechsc] Problem with DTMF type-ahead Date: Tue, 23 Aug 2005 20:29:10 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.8 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0485555099==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0485555099== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0493_01C5A821.51C8FA00" This is a multi-part message in MIME format. ------=_NextPart_000_0493_01C5A821.51C8FA00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Problem with DTMF type-aheadNice catch. This is a must fix in my = opinion. Here's my thought on a resolution: By default, the recognizer (dtmfrecog or speechrecog) should buffer = DTMF. This means that if some DTMF digits are entered outside of the = Recognizing State and a RECOGNIZE request made later, the buffered = digits and their timings are applied to that recognition. To clear the = buffer, a header can be added to RECOGNIZE called Clear-DTMF-Buffer: = true. Any DTMF digits buffered up to that point are discarded.=20 Can supply the text changes if that's helpful (also note small = refactoring needed in last sentence of section 9.9 regarding not = buffering anything before RECOGNIZE).=20 Dave ----- Original Message -----=20 From: Reifenrath, Klaus=20 To: 'sarvi@cisco.com' ; 'dburnett@vocalocity.net'=20 Cc: 'speechsc@ietf.org'=20 Sent: Tuesday, August 23, 2005 4:41 PM Subject: [Speechsc] Problem with DTMF type-ahead=20 The MRCP and MRCPv2 specifications define how DTMF input should be = handled: DTMF input is collected after the RECOGNIZE request is received = until a term-char or timeout is reached. Then a result or no-match is = returned based on any active DTMF grammars. The problem is there can be = a significant amount of time between when one result is processed by the = application and the next grammar is activated. During that time any DTMF = input received will be lost. Such DTMF type-ahead is common for frequent = users of IVR systems, and buffering that type ahead is required by = VoiceXML 2.0 (see section 4.1.8). Can this requirement of VoiceXML be = implemented using MRCP (assuming that the media source CANNOT buffer = DTMF)? If so, how is it done?=20 Thanks, Klaus=20 -------------------------------------------------------------------------= ----- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc ------=_NextPart_000_0493_01C5A821.51C8FA00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Problem with DTMF type-ahead
Nice catch. This is a must fix in my=20 opinion.
 
Here's my thought on a=20 resolution:
 
By default, the recognizer (dtmfrecog = or=20 speechrecog) should buffer DTMF. This means that if some DTMF digits are = entered outside of the Recognizing State and a RECOGNIZE request = made=20 later, the buffered digits and their timings are applied to that = recognition. To=20 clear the buffer, a header can be added to RECOGNIZE called = Clear-DTMF-Buffer:=20 true. Any DTMF digits buffered up to that point are discarded.=20
 
Can supply the text changes if that's = helpful (also=20 note small refactoring needed in last sentence of section 9.9 regarding = not=20 buffering anything before RECOGNIZE).
 
Dave
 
 
----- Original Message -----
From:=20 Reifenrath, Klaus =
To: 'sarvi@cisco.com' ; 'dburnett@vocalocity.net' =
Sent: Tuesday, August 23, 2005 = 4:41=20 PM
Subject: [Speechsc] Problem = with DTMF=20 type-ahead

The MRCP and MRCPv2 specifications = define how DTMF=20 input should be handled: DTMF input is collected after the RECOGNIZE = request=20 is received until a term-char or timeout is reached. Then a result or = no-match=20 is returned based on any active DTMF grammars. The problem is there = can be a=20 significant amount of time between when one result is processed by the = application and the next grammar is activated. During that time any = DTMF input=20 received will be lost. Such DTMF type-ahead is common for frequent = users of=20 IVR systems, and buffering that type ahead is required by VoiceXML 2.0 = (see=20 section 4.1.8). Can this requirement of VoiceXML be implemented using MRCP = (assuming that=20 the media source CANNOT buffer DTMF)? If so, how is it done? =

Thanks,
Klaus

_______________________________________________
Speechsc = mailing=20 = list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speec= hsc
------=_NextPart_000_0493_01C5A821.51C8FA00-- --===============0485555099== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============0485555099==-- From speechsc-bounces@ietf.org Tue Aug 23 16:36:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7fVU-0000VV-KK; Tue, 23 Aug 2005 16:36:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7fVS-0000VK-M4 for speechsc@megatron.ietf.org; Tue, 23 Aug 2005 16:36:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09922 for ; Tue, 23 Aug 2005 16:36:24 -0400 (EDT) Received: from letter.nuance.com ([207.107.210.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7fVa-000510-EI for speechsc@ietf.org; Tue, 23 Aug 2005 16:36:38 -0400 Received: from postcard.nuance.com ([10.3.6.20]:8249) by letter.nuance.com with esmtp id 1E7fV6-0007b9-0W; Tue, 23 Aug 2005 13:36:04 -0700 Received: from mtb1exch01.nuance.com ([10.3.2.6]) by postcard.nuance.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 23 Aug 2005 16:35:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speechsc] Problem with DTMF type-ahead Date: Tue, 23 Aug 2005 16:35:56 -0400 Message-ID: <7DE7C4EF3B7C8B4B82955191378290D80322823D@mtb1exch01.nuance.com> Thread-Topic: [Speechsc] Problem with DTMF type-ahead Thread-Index: AcWoGUIClKcNxpvCQS6zMzmZkGjMqgACHAJQ From: "Pierre Forgues" To: "Dave Burke" , "Klaus Reifenrath" , , X-OriginalArrivalTime: 23 Aug 2005 20:35:58.0520 (UTC) FILETIME=[44B82380:01C5A822] X-FromHost: postcard.nuance.com [10.3.6.20]:8249 Lines: 494 X-Spam-Score: 0.2 (/) X-Scan-Signature: 4a96669441ad70ecf6aebb4b47b971cd Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0470268535==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0470268535== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A822.43E0AAF2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A822.43E0AAF2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We agree with this position. =20 =20 We have implemented dtmf type ahead in our product and adding a header to give the application the choice to clear the buffer on the next RECOGNIZE but by default operating on the dtmf buffer is the right decision. /Pierre =20 ________________________________ From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke Sent: Tuesday, August 23, 2005 3:29 PM To: Klaus Reifenrath; sarvi@cisco.com; dburnett@vocalocity.net Cc: speechsc@ietf.org Subject: Re: [Speechsc] Problem with DTMF type-ahead=20 =20 Nice catch. This is a must fix in my opinion. =20 Here's my thought on a resolution: =20 By default, the recognizer (dtmfrecog or speechrecog) should buffer DTMF. This means that if some DTMF digits are entered outside of the Recognizing State and a RECOGNIZE request made later, the buffered digits and their timings are applied to that recognition. To clear the buffer, a header can be added to RECOGNIZE called Clear-DTMF-Buffer: true. Any DTMF digits buffered up to that point are discarded.=20 =20 Can supply the text changes if that's helpful (also note small refactoring needed in last sentence of section 9.9 regarding not buffering anything before RECOGNIZE).=20 =20 Dave =20 =20 ----- Original Message -----=20 From: Reifenrath, Klaus =20 To: 'sarvi@cisco.com' ; 'dburnett@vocalocity.net'=20 Cc: 'speechsc@ietf.org'=20 Sent: Tuesday, August 23, 2005 4:41 PM Subject: [Speechsc] Problem with DTMF type-ahead=20 =20 The MRCP and MRCPv2 specifications define how DTMF input should be handled: DTMF input is collected after the RECOGNIZE request is received until a term-char or timeout is reached. Then a result or no-match is returned based on any active DTMF grammars. The problem is there can be a significant amount of time between when one result is processed by the application and the next grammar is activated. During that time any DTMF input received will be lost. Such DTMF type-ahead is common for frequent users of IVR systems, and buffering that type ahead is required by VoiceXML 2.0 (see section 4.1.8). Can this requirement of VoiceXML be implemented using MRCP (assuming that the media source CANNOT buffer DTMF)? If so, how is it done?=20 Thanks, Klaus=20 =09 ________________________________ _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc ------_=_NextPart_001_01C5A822.43E0AAF2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Problem with DTMF type-ahead

We agree with this position. =  

 

We have implemented dtmf type ahead = in our product and adding a header to give the application the choice to clear = the buffer on the next RECOGNIZE but by default operating on the dtmf buffer = is the right decision.  /Pierre

 

From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke
Sent: Tuesday, August 23, = 2005 3:29 PM
To: Klaus Reifenrath; sarvi@cisco.com; = dburnett@vocalocity.net
Cc: speechsc@ietf.org
Subject: Re: [Speechsc] = Problem with DTMF type-ahead

 

Nice catch. This is a must fix in my = opinion.

 

Here's my thought on a = resolution:

 

By default, the recognizer (dtmfrecog or speechrecog) = should buffer DTMF. This means that if some DTMF digits are = entered outside of the Recognizing State and a RECOGNIZE request = made later, the buffered digits and their timings are applied to that = recognition. To clear the buffer, a header can be added to RECOGNIZE called Clear-DTMF-Buffer: true. Any DTMF digits buffered up to that point = are discarded.

 

Can supply the text changes if that's helpful (also = note small refactoring needed in last sentence of section 9.9 regarding not buffering anything before RECOGNIZE).

 

Dave

 

 

----- Original Message ----- =

Sent: = Tuesday, August 23, 2005 4:41 PM

Subject: = [Speechsc] Problem with DTMF type-ahead

 

The MRCP and MRCPv2 specifications define how DTMF input should be handled: = DTMF input is collected after the RECOGNIZE request is received until a = term-char or timeout is reached. Then a result or no-match is returned based on any = active DTMF grammars. The problem is there can be a significant amount of time = between when one result is processed by the application and the next grammar is activated. During that time any DTMF input received will be lost. Such = DTMF type-ahead is common for frequent users of IVR systems, and buffering = that type ahead is required by VoiceXML 2.0 (see section 4.1.8). = Can this requirement of VoiceXML be implemented using MRCP (assuming that the = media source CANNOT buffer DTMF)? If so, how is it done? =

Thanks,
Klaus

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc<= /p>

------_=_NextPart_001_01C5A822.43E0AAF2-- --===============0470268535== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============0470268535==-- From speechsc-bounces@ietf.org Tue Aug 23 16:59:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7frc-0001gl-5g; Tue, 23 Aug 2005 16:59:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7frY-0001fd-Hz for speechsc@megatron.ietf.org; Tue, 23 Aug 2005 16:59:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11535 for ; Tue, 23 Aug 2005 16:59:14 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7frh-0005pK-L8 for speechsc@ietf.org; Tue, 23 Aug 2005 16:59:28 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 23 Aug 2005 13:59:05 -0700 X-IronPort-AV: i="3.96,135,1122879600"; d="scan'208,217"; a="207047677:sNHT44212952" Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j7NKwe38027417; Tue, 23 Aug 2005 13:59:02 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 23 Aug 2005 13:59:00 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C2C41C5@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: Problem with DTMF type-ahead Thread-Index: AcWn+6tjuWWuWeMTTXKPwEhMTCB1xgABfb3w From: "Shanmugham, Saravanan" To: "Reifenrath, Klaus" , X-Spam-Score: 0.9 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: speechsc@ietf.org Subject: [Speechsc] RE: Problem with DTMF type-ahead X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1056277255==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1056277255== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A825.7CF6D11D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A825.7CF6D11D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 I had typed this response out earlier but wanted to see if there was any support for this capability. So sending it out now. =20 The solution I would suggest is a new header=20 Type-Ahead: =20 header that can be sent on the SET-PARAMS, GET-PARAMS and RECOGNIZE methods. =20 default is 0 which is todays no buffering case. If set to some value, the resource is expected to buffer upto of audio and use it during the recognize as a type-ahead buffer. I can see this being a boolean field as well, but the approach is little more flexible. =20 Sarvi ________________________________ From: Reifenrath, Klaus [mailto:Klaus.Reifenrath@Scansoft.com]=20 Sent: Tuesday, August 23, 2005 8:41 AM To: Shanmugham, Saravanan; 'dburnett@vocalocity.net' Cc: 'speechsc@ietf.org' Subject: Problem with DTMF type-ahead=20 =09 =09 The MRCP and MRCPv2 specifications define how DTMF input should be handled: DTMF input is collected after the RECOGNIZE request is received until a term-char or timeout is reached. Then a result or no-match is returned based on any active DTMF grammars. The problem is there can be a significant amount of time between when one result is processed by the application and the next grammar is activated. During that time any DTMF input received will be lost. Such DTMF type-ahead is common for frequent users of IVR systems, and buffering that type ahead is required by VoiceXML 2.0 (see section 4.1.8). Can this requirement of VoiceXML be implemented using MRCP (assuming that the media source CANNOT buffer DTMF)? If so, how is it done?=20 Thanks, Klaus=20 ------_=_NextPart_001_01C5A825.7CF6D11D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Problem with DTMF type-ahead
 
I had typed this response out earlier but = wanted to see=20 if there was any support for this capability. So sending it out=20 now.
 
The solution I would suggest is a new header=20
       &nbs= p;  =20 Type-Ahead: <time-in-milli-seconds>
header that can be sent on the SET-PARAMS, = GET-PARAMS=20 and RECOGNIZE methods.
 
default is 0 which is todays no buffering = case. If set=20 to some value, the resource is expected to buffer upto=20 <time-in-milliseconds> of audio and use it during the recognize as = a=20 type-ahead buffer. I can see this being a boolean field as well, but the = <time-in-milliseconds> approach is little more=20 flexible.
 
Sarvi

From: Reifenrath, Klaus=20 [mailto:Klaus.Reifenrath@Scansoft.com]
Sent: Tuesday, = August 23,=20 2005 8:41 AM
To: Shanmugham, Saravanan;=20 'dburnett@vocalocity.net'
Cc: = 'speechsc@ietf.org'
Subject:=20 Problem with DTMF type-ahead

The MRCP and MRCPv2 specifications = define how DTMF=20 input should be handled: DTMF input is collected after the RECOGNIZE = request=20 is received until a term-char or timeout is reached. Then a result or = no-match=20 is returned based on any active DTMF grammars. The problem is there = can be a=20 significant amount of time between when one result is processed by the = application and the next grammar is activated. During that time any = DTMF input=20 received will be lost. Such DTMF type-ahead is common for frequent = users of=20 IVR systems, and buffering that type ahead is required by VoiceXML 2.0 = (see=20 section 4.1.8). Can this requirement of VoiceXML be implemented using MRCP = (assuming that=20 the media source CANNOT buffer DTMF)? If so, how is it done? =

Thanks,
Klaus=20

------_=_NextPart_001_01C5A825.7CF6D11D-- --===============1056277255== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============1056277255==-- From speechsc-bounces@ietf.org Tue Aug 23 17:24:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7gFp-00086x-HW; Tue, 23 Aug 2005 17:24:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7gFo-00086s-G0 for speechsc@megatron.ietf.org; Tue, 23 Aug 2005 17:24:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12857 for ; Tue, 23 Aug 2005 17:24:18 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7gFw-0006ap-9O for speechsc@ietf.org; Tue, 23 Aug 2005 17:24:29 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 23 Aug 2005 14:23:50 -0700 X-IronPort-AV: i="3.96,135,1122879600"; d="scan'208"; a="207051746:sNHT47804533230" Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j7NLNaZ7028544; Tue, 23 Aug 2005 14:23:42 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Recognition Completion-Cause Codes 003 and 008 revisited Date: Tue, 23 Aug 2005 14:21:38 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C2C41CA@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] Recognition Completion-Cause Codes 003 and 008 revisited Thread-Index: AcWn8DBSk53rlDwHSgW+Bg7zWDr3zQAN+GFw From: "Shanmugham, Saravanan" To: "Andrew Wahbe" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org I was going to remove Recognition-Timeout based on the thread on the confusion between this cause and max-speech-timeout etc. But it was agreed we need a timeout capability for HotWord Recognition based ona separate thread. In the hotword case, none of the timeout desciptions match the way timeout happens in hotword recognition. Since there, even if the words spoken until that point did not match any of the hotwords, the recognition would still continue. Hence a separate completion code for hotword recognition timeout was needed. And I have used 03 for that use case. Sarvi -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Andrew Wahbe Sent: Tuesday, August 23, 2005 7:34 AM To: speechsc@ietf.org Subject: [Speechsc] Recognition Completion-Cause Codes 003=20 and 008 revisited =20 A few weeks ago, there was an extensive discussion about=20 the recognition completion-cause codes for cases where=20 recognition-timers fire. There seemed to be two codes, 003=20 and 008, that meant the same thing -- the recognition was=20 aborted due to the recognition-timer firing. This case=20 maps to the maxspeechtimeout event in VoiceXML. =20 A lot of hypothesizing was done to try and figure out what=20 the difference between the codes was. After some=20 discussion it seems we ended up with no codes that map to=20 maxspeechtimeout in VoiceXML (i.e.=20 the recognition was aborted because of recognition-timeout=20 and there is no match). =20 I think things would be set right if 003 was changed from: =20 | 003 | recognition-timeout | RECOGNIZE in hotword=20 mode | | | | completed without a=20 match due to | | | | a=20 recognition-timeout | =20 to: =20 | 003 | recognition-timeout | RECOGNIZE completed=20 without a | | | | match due to a =20 | | | | recognition-timeout =20 | =20 =20 I am not sure why a special code is needed for this timer=20 firing in hotword mode. Am I missing something? =20 Andrew Wahbe VoiceGenie Technologies =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue Aug 23 18:20:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7h7p-0002G5-AC; Tue, 23 Aug 2005 18:20:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7h7m-0002Fx-15 for speechsc@megatron.ietf.org; Tue, 23 Aug 2005 18:20:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16315 for ; Tue, 23 Aug 2005 18:20:03 -0400 (EDT) Received: from mail.vocalocity.net ([38.116.10.177] helo=smtp.vocalocity.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7h7y-0008Ed-04 for speechsc@ietf.org; Tue, 23 Aug 2005 18:20:18 -0400 Received: by smtp.vocalocity.net (Postfix, from userid 9999) id 4C1EE16CE00; Tue, 23 Aug 2005 18:19:48 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead Date: Tue, 23 Aug 2005 18:19:44 -0400 Message-ID: <92E86BBD06161E4299A56009516472ED9BC7A3@gates.vcorp.vocalocity.net> Thread-Topic: [Speechsc] RE: Problem with DTMF type-ahead Thread-Index: AcWn+6tjuWWuWeMTTXKPwEhMTCB1xgABfb3wAAu+kHA= From: "Jeff Haynie" To: "Shanmugham, Saravanan" , "Reifenrath, Klaus" , X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on revelation.vcorp.vocalocity.net X-Spam-Status: No, score=-5.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, HTML_MESSAGE autolearn=ham version=3.0.4 X-Spam-Score: 0.6 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1872997488==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1872997488== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A830.C447F4FF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A830.C447F4FF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It would seem like we're not trying to buffer audio (generally) but only the DIGIT values themselves. =20 It would seem better to just be a header such as: =20 DTMF-Buffer: =20 instead. =20 Jeff ________________________________ From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Shanmugham, Saravanan Sent: Tuesday, August 23, 2005 4:59 PM To: Reifenrath, Klaus; dburnett@vocalocity.net Cc: speechsc@ietf.org Subject: [Speechsc] RE: Problem with DTMF type-ahead=20 =20 I had typed this response out earlier but wanted to see if there was any support for this capability. So sending it out now. =20 The solution I would suggest is a new header=20 Type-Ahead: =20 header that can be sent on the SET-PARAMS, GET-PARAMS and RECOGNIZE methods. =20 default is 0 which is todays no buffering case. If set to some value, the resource is expected to buffer upto of audio and use it during the recognize as a type-ahead buffer. I can see this being a boolean field as well, but the approach is little more flexible. =20 Sarvi ________________________________ From: Reifenrath, Klaus [mailto:Klaus.Reifenrath@Scansoft.com]=20 Sent: Tuesday, August 23, 2005 8:41 AM To: Shanmugham, Saravanan; 'dburnett@vocalocity.net' Cc: 'speechsc@ietf.org' Subject: Problem with DTMF type-ahead=20 =09 =09 The MRCP and MRCPv2 specifications define how DTMF input should be handled: DTMF input is collected after the RECOGNIZE request is received until a term-char or timeout is reached. Then a result or no-match is returned based on any active DTMF grammars. The problem is there can be a significant amount of time between when one result is processed by the application and the next grammar is activated. During that time any DTMF input received will be lost. Such DTMF type-ahead is common for frequent users of IVR systems, and buffering that type ahead is required by VoiceXML 2.0 (see section 4.1.8). Can this requirement of VoiceXML be implemented using MRCP (assuming that the media source CANNOT buffer DTMF)? If so, how is it done?=20 Thanks, Klaus=20 ------_=_NextPart_001_01C5A830.C447F4FF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Problem with DTMF type-ahead
It would seem like we're not trying to buffer = audio=20 (generally) but only the DIGIT values themselves. =20

It would seem=20 better to just be a header such as:
 
DTMF-Buffer: = <true|false>
 
instead.
 
Jeff

From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Shanmugham,=20 Saravanan
Sent: Tuesday, August 23, 2005 4:59 PM
To: = Reifenrath, Klaus; dburnett@vocalocity.net
Cc:=20 speechsc@ietf.org
Subject: [Speechsc] RE: Problem with DTMF = type-ahead=20

 
I had typed this response out earlier but = wanted to see=20 if there was any support for this capability. So sending it out=20 now.
 
The solution I would suggest is a new header=20
       &nbs= p;  =20 Type-Ahead: <time-in-milli-seconds>
header that can be sent on the SET-PARAMS, = GET-PARAMS=20 and RECOGNIZE methods.
 
default is 0 which is todays no buffering = case. If set=20 to some value, the resource is expected to buffer upto=20 <time-in-milliseconds> of audio and use it during the recognize as = a=20 type-ahead buffer. I can see this being a boolean field as well, but the = <time-in-milliseconds> approach is little more=20 flexible.
 
Sarvi

From: Reifenrath, Klaus=20 [mailto:Klaus.Reifenrath@Scansoft.com]
Sent: Tuesday, = August 23,=20 2005 8:41 AM
To: Shanmugham, Saravanan;=20 'dburnett@vocalocity.net'
Cc: = 'speechsc@ietf.org'
Subject:=20 Problem with DTMF type-ahead

The MRCP and MRCPv2 specifications = define how DTMF=20 input should be handled: DTMF input is collected after the RECOGNIZE = request=20 is received until a term-char or timeout is reached. Then a result or = no-match=20 is returned based on any active DTMF grammars. The problem is there = can be a=20 significant amount of time between when one result is processed by the = application and the next grammar is activated. During that time any = DTMF input=20 received will be lost. Such DTMF type-ahead is common for frequent = users of=20 IVR systems, and buffering that type ahead is required by VoiceXML 2.0 = (see=20 section 4.1.8). Can this requirement of VoiceXML be implemented using MRCP = (assuming that=20 the media source CANNOT buffer DTMF)? If so, how is it done? =

Thanks,
Klaus=20

------_=_NextPart_001_01C5A830.C447F4FF-- --===============1872997488== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============1872997488==-- From speechsc-bounces@ietf.org Tue Aug 23 18:31:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7hIL-0005ZY-3E; Tue, 23 Aug 2005 18:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7hII-0005YD-Tb for speechsc@megatron.ietf.org; Tue, 23 Aug 2005 18:30:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16960 for ; Tue, 23 Aug 2005 18:30:56 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7hIU-0008V4-W6 for speechsc@ietf.org; Tue, 23 Aug 2005 18:31:11 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 23 Aug 2005 15:30:47 -0700 Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j7NMUcZ7014954; Tue, 23 Aug 2005 15:30:44 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead Date: Tue, 23 Aug 2005 15:30:39 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C2C41E6@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] RE: Problem with DTMF type-ahead Thread-Index: AcWn+6tjuWWuWeMTTXKPwEhMTCB1xgABfb3wAAu+kHAAAF9z8A== From: "Shanmugham, Saravanan" To: "Jeff Haynie" , "Reifenrath, Klaus" , X-Spam-Score: 0.6 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1022289935==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1022289935== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A832.4AAB8C5F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A832.4AAB8C5F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Are we assuming then that this is only limited to DTMF type-ahead and is not speak ahead as well? =20 Sarvi ________________________________ From: Jeff Haynie [mailto:jhaynie@vocalocity.net]=20 Sent: Tuesday, August 23, 2005 3:20 PM To: Shanmugham, Saravanan; Reifenrath, Klaus; dburnett@vocalocity.net Cc: speechsc@ietf.org Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead=20 =09 =09 It would seem like we're not trying to buffer audio (generally) but only the DIGIT values themselves. =20 =09 It would seem better to just be a header such as: =20 DTMF-Buffer: =20 instead. =20 Jeff ________________________________ From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Shanmugham, Saravanan Sent: Tuesday, August 23, 2005 4:59 PM To: Reifenrath, Klaus; dburnett@vocalocity.net Cc: speechsc@ietf.org Subject: [Speechsc] RE: Problem with DTMF type-ahead=20 =09 =09 =20 I had typed this response out earlier but wanted to see if there was any support for this capability. So sending it out now. =20 The solution I would suggest is a new header=20 Type-Ahead: =20 header that can be sent on the SET-PARAMS, GET-PARAMS and RECOGNIZE methods. =20 default is 0 which is todays no buffering case. If set to some value, the resource is expected to buffer upto of audio and use it during the recognize as a type-ahead buffer. I can see this being a boolean field as well, but the approach is little more flexible. =20 Sarvi ________________________________ From: Reifenrath, Klaus [mailto:Klaus.Reifenrath@Scansoft.com]=20 Sent: Tuesday, August 23, 2005 8:41 AM To: Shanmugham, Saravanan; 'dburnett@vocalocity.net' Cc: 'speechsc@ietf.org' Subject: Problem with DTMF type-ahead=20 =09 =09 The MRCP and MRCPv2 specifications define how DTMF input should be handled: DTMF input is collected after the RECOGNIZE request is received until a term-char or timeout is reached. Then a result or no-match is returned based on any active DTMF grammars. The problem is there can be a significant amount of time between when one result is processed by the application and the next grammar is activated. During that time any DTMF input received will be lost. Such DTMF type-ahead is common for frequent users of IVR systems, and buffering that type ahead is required by VoiceXML 2.0 (see section 4.1.8). Can this requirement of VoiceXML be implemented using MRCP (assuming that the media source CANNOT buffer DTMF)? If so, how is it done?=20 Thanks, Klaus=20 ------_=_NextPart_001_01C5A832.4AAB8C5F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Problem with DTMF type-ahead
Are we assuming then that this is = only limited=20 to DTMF type-ahead and is not speak ahead as = well?
 
Sarvi

From: Jeff Haynie=20 [mailto:jhaynie@vocalocity.net]
Sent: Tuesday, August 23, = 2005 3:20=20 PM
To: Shanmugham, Saravanan; Reifenrath, Klaus;=20 dburnett@vocalocity.net
Cc: = speechsc@ietf.org
Subject: RE:=20 [Speechsc] RE: Problem with DTMF type-ahead

It would seem like we're not trying to buffer = audio=20 (generally) but only the DIGIT values themselves. =20

It would=20 seem better to just be a header such as:
 
DTMF-Buffer: = <true|false>
 
instead.
 
Jeff

From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Shanmugham,=20 Saravanan
Sent: Tuesday, August 23, 2005 4:59 = PM
To:=20 Reifenrath, Klaus; dburnett@vocalocity.net
Cc:=20 speechsc@ietf.org
Subject: [Speechsc] RE: Problem with DTMF=20 type-ahead

 
I had typed this response out earlier but = wanted to=20 see if there was any support for this capability. So sending it out=20 now.
 
The solution I would suggest is a new = header=20
       &nbs= p;  =20 Type-Ahead: <time-in-milli-seconds>
header that can be sent on the SET-PARAMS, = GET-PARAMS=20 and RECOGNIZE methods.
 
default is 0 which is todays no buffering = case. If=20 set to some value, the resource is expected to buffer upto=20 <time-in-milliseconds> of audio and use it during the recognize = as a=20 type-ahead buffer. I can see this being a boolean field as well, but = the=20 <time-in-milliseconds> approach is little more=20 flexible.
 
Sarvi

From: Reifenrath, Klaus=20 [mailto:Klaus.Reifenrath@Scansoft.com]
Sent: Tuesday, = August 23,=20 2005 8:41 AM
To: Shanmugham, Saravanan;=20 'dburnett@vocalocity.net'
Cc:=20 'speechsc@ietf.org'
Subject: Problem with DTMF type-ahead=20

The MRCP and MRCPv2 specifications = define how=20 DTMF input should be handled: DTMF input is collected after the = RECOGNIZE=20 request is received until a term-char or timeout is reached. Then a = result=20 or no-match is returned based on any active DTMF grammars. The = problem is=20 there can be a significant amount of time between when one result is = processed by the application and the next grammar is activated. = During that=20 time any DTMF input received will be lost. Such DTMF type-ahead is = common=20 for frequent users of IVR systems, and buffering that type ahead is = required=20 by VoiceXML 2.0 (see section 4.1.8).=20 Can this requirement of VoiceXML = be=20 implemented using MRCP (assuming that the media source CANNOT buffer = DTMF)?=20 If so, how is it done?

Thanks,
Klaus=20

------_=_NextPart_001_01C5A832.4AAB8C5F-- --===============1022289935== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============1022289935==-- From speechsc-bounces@ietf.org Tue Aug 23 19:34:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7iHV-0005DQ-Ak; Tue, 23 Aug 2005 19:34:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7iHT-0005DL-LJ for speechsc@megatron.ietf.org; Tue, 23 Aug 2005 19:34:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19639 for ; Tue, 23 Aug 2005 19:34:08 -0400 (EDT) Received: from mail02.corp.tellme.com ([209.157.157.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7iHf-0001gn-BY for speechsc@ietf.org; Tue, 23 Aug 2005 19:34:24 -0400 Received: from mail02.corp.tellme.com (localhost [127.0.0.1]) by localhost.corp.tellme.com (Postfix) with ESMTP id 99970350D for ; Tue, 23 Aug 2005 16:33:41 -0700 (PDT) Received: from [172.20.51.124] (dhcp172-51-124.corp.tellme.com [172.20.51.124]) by mail02.corp.tellme.com (Postfix) with ESMTP id 4DDCC3507 for ; Tue, 23 Aug 2005 16:33:41 -0700 (PDT) Message-ID: <430BB254.3050501@tellme.com> Date: Tue, 23 Aug 2005 16:33:40 -0700 From: Corby Anderson User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: speechsc@ietf.org Subject: Re: [Speechsc] RE: Problem with DTMF type-ahead References: <03772D1EC8DE624A863058C75874A75C2C41E6@vtg-um-e2k6.sj21ad.cisco.com> In-Reply-To: <03772D1EC8DE624A863058C75874A75C2C41E6@vtg-um-e2k6.sj21ad.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org I prefer the flexible "Type-Ahead: " approach. This would be useful for implementing vxml listen states that happen after data tags. If a data fetch takes longer than several seconds, you might not want to play dtmf that is older than some limit. Corby Anderson Tellme Networks, Inc. Shanmugham, Saravanan wrote: > Are we assuming then that this is only limited to DTMF type-ahead and > is not speak ahead as well? > > Sarvi > > ------------------------------------------------------------------------ > *From:* Jeff Haynie [mailto:jhaynie@vocalocity.net] > *Sent:* Tuesday, August 23, 2005 3:20 PM > *To:* Shanmugham, Saravanan; Reifenrath, Klaus; > dburnett@vocalocity.net > *Cc:* speechsc@ietf.org > *Subject:* RE: [Speechsc] RE: Problem with DTMF type-ahead > > It would seem like we're not trying to buffer audio (generally) > but only the DIGIT values themselves. > > It would seem better to just be a header such as: > > DTMF-Buffer: > > instead. > > Jeff > > ------------------------------------------------------------------------ > *From:* speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] *On Behalf Of *Shanmugham, > Saravanan > *Sent:* Tuesday, August 23, 2005 4:59 PM > *To:* Reifenrath, Klaus; dburnett@vocalocity.net > *Cc:* speechsc@ietf.org > *Subject:* [Speechsc] RE: Problem with DTMF type-ahead > > > I had typed this response out earlier but wanted to see if there > was any support for this capability. So sending it out now. > > The solution I would suggest is a new header > Type-Ahead: > header that can be sent on the SET-PARAMS, GET-PARAMS and > RECOGNIZE methods. > > default is 0 which is todays no buffering case. If set to some > value, the resource is expected to buffer upto > of audio and use it during the recognize as > a type-ahead buffer. I can see this being a boolean field as well, > but the approach is little more flexible. > > Sarvi > > ------------------------------------------------------------------------ > *From:* Reifenrath, Klaus [mailto:Klaus.Reifenrath@Scansoft.com] > *Sent:* Tuesday, August 23, 2005 8:41 AM > *To:* Shanmugham, Saravanan; 'dburnett@vocalocity.net' > *Cc:* 'speechsc@ietf.org' > *Subject:* Problem with DTMF type-ahead > > The MRCP and MRCPv2 specifications define how DTMF input > should be handled: DTMF input is collected after the RECOGNIZE > request is received until a term-char or timeout is reached. > Then a result or no-match is returned based on any active DTMF > grammars. The problem is there can be a significant amount of > time between when one result is processed by the application > and the next grammar is activated. During that time any DTMF > input received will be lost. Such DTMF type-ahead is common > for frequent users of IVR systems, and buffering that type > ahead is required by VoiceXML 2.0 (see section 4.1.8). Can > this requirement of VoiceXML be implemented using MRCP > (assuming that the media source CANNOT buffer DTMF)? If so, > how is it done? > > Thanks, > Klaus > >------------------------------------------------------------------------ > >_______________________________________________ >Speechsc mailing list >Speechsc@ietf.org >https://www1.ietf.org/mailman/listinfo/speechsc > > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue Aug 23 20:04:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ikx-0006ws-LL; Tue, 23 Aug 2005 20:04:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ikv-0006wa-Qo for speechsc@megatron.ietf.org; Tue, 23 Aug 2005 20:04:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21034 for ; Tue, 23 Aug 2005 20:04:36 -0400 (EDT) Received: from mail.vocalocity.net ([38.116.10.177] helo=smtp.vocalocity.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7il8-0002Wn-QO for speechsc@ietf.org; Tue, 23 Aug 2005 20:04:51 -0400 Received: by smtp.vocalocity.net (Postfix, from userid 9999) id 8288A16CDFE; Tue, 23 Aug 2005 20:04:28 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead Date: Tue, 23 Aug 2005 20:04:24 -0400 Message-ID: <92E86BBD06161E4299A56009516472ED9BC7BF@gates.vcorp.vocalocity.net> Thread-Topic: [Speechsc] RE: Problem with DTMF type-ahead Thread-Index: AcWn+6tjuWWuWeMTTXKPwEhMTCB1xgABfb3wAAu+kHAAAF9z8AADR/FQ From: "Jeff Haynie" To: "Shanmugham, Saravanan" , "Reifenrath, Klaus" , X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on revelation.vcorp.vocalocity.net X-Spam-Status: No, score=-5.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, HTML_MESSAGE autolearn=ham version=3.0.4 X-Spam-Score: 0.6 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0272124757==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0272124757== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A83F.6347157D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A83F.6347157D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sarvi, et al: =20 Is there a use case for speak ahead? I can't honestly think of one ... maybe Dan or someone else knows of one they could speak too. It also seems like that would introduce a lot of other complexity with partial packets, etc. that you isn't the case with DTMF. =20 Jeff ________________________________ From: Shanmugham, Saravanan [mailto:sarvi@cisco.com]=20 Sent: Tuesday, August 23, 2005 6:31 PM To: Jeff Haynie; Reifenrath, Klaus; dburnett@vocalocity.net Cc: speechsc@ietf.org Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead=20 Are we assuming then that this is only limited to DTMF type-ahead and is not speak ahead as well? =20 Sarvi ________________________________ From: Jeff Haynie [mailto:jhaynie@vocalocity.net]=20 Sent: Tuesday, August 23, 2005 3:20 PM To: Shanmugham, Saravanan; Reifenrath, Klaus; dburnett@vocalocity.net Cc: speechsc@ietf.org Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead=20 =09 =09 It would seem like we're not trying to buffer audio (generally) but only the DIGIT values themselves. =20 =09 It would seem better to just be a header such as: =20 DTMF-Buffer: =20 instead. =20 Jeff ________________________________ From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Shanmugham, Saravanan Sent: Tuesday, August 23, 2005 4:59 PM To: Reifenrath, Klaus; dburnett@vocalocity.net Cc: speechsc@ietf.org Subject: [Speechsc] RE: Problem with DTMF type-ahead=20 =09 =09 =20 I had typed this response out earlier but wanted to see if there was any support for this capability. So sending it out now. =20 The solution I would suggest is a new header=20 Type-Ahead: =20 header that can be sent on the SET-PARAMS, GET-PARAMS and RECOGNIZE methods. =20 default is 0 which is todays no buffering case. If set to some value, the resource is expected to buffer upto of audio and use it during the recognize as a type-ahead buffer. I can see this being a boolean field as well, but the approach is little more flexible. =20 Sarvi ________________________________ From: Reifenrath, Klaus [mailto:Klaus.Reifenrath@Scansoft.com]=20 Sent: Tuesday, August 23, 2005 8:41 AM To: Shanmugham, Saravanan; 'dburnett@vocalocity.net' Cc: 'speechsc@ietf.org' Subject: Problem with DTMF type-ahead=20 =09 =09 The MRCP and MRCPv2 specifications define how DTMF input should be handled: DTMF input is collected after the RECOGNIZE request is received until a term-char or timeout is reached. Then a result or no-match is returned based on any active DTMF grammars. The problem is there can be a significant amount of time between when one result is processed by the application and the next grammar is activated. During that time any DTMF input received will be lost. Such DTMF type-ahead is common for frequent users of IVR systems, and buffering that type ahead is required by VoiceXML 2.0 (see section 4.1.8). Can this requirement of VoiceXML be implemented using MRCP (assuming that the media source CANNOT buffer DTMF)? If so, how is it done?=20 Thanks, Klaus=20 ------_=_NextPart_001_01C5A83F.6347157D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Problem with DTMF type-ahead
Sarvi, et al:
 
Is there a use case for speak ahead?  I = can't honestly=20 think of one ... maybe Dan or someone else knows of one they could = speak=20 too.  It also seems like that would introduce a lot of other = complexity=20 with partial packets, etc. that you isn't the case with=20 DTMF.
 
Jeff

From: Shanmugham, Saravanan=20 [mailto:sarvi@cisco.com]
Sent: Tuesday, August 23, 2005 6:31=20 PM
To: Jeff Haynie; Reifenrath, Klaus;=20 dburnett@vocalocity.net
Cc: = speechsc@ietf.org
Subject: RE:=20 [Speechsc] RE: Problem with DTMF type-ahead

Are we assuming then that this is = only limited=20 to DTMF type-ahead and is not speak ahead as = well?
 
Sarvi

From: Jeff Haynie=20 [mailto:jhaynie@vocalocity.net]
Sent: Tuesday, August 23, = 2005 3:20=20 PM
To: Shanmugham, Saravanan; Reifenrath, Klaus;=20 dburnett@vocalocity.net
Cc: = speechsc@ietf.org
Subject: RE:=20 [Speechsc] RE: Problem with DTMF type-ahead

It would seem like we're not trying to buffer = audio=20 (generally) but only the DIGIT values themselves. =20

It would=20 seem better to just be a header such as:
 
DTMF-Buffer: = <true|false>
 
instead.
 
Jeff

From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Shanmugham,=20 Saravanan
Sent: Tuesday, August 23, 2005 4:59 = PM
To:=20 Reifenrath, Klaus; dburnett@vocalocity.net
Cc:=20 speechsc@ietf.org
Subject: [Speechsc] RE: Problem with DTMF=20 type-ahead

 
I had typed this response out earlier but = wanted to=20 see if there was any support for this capability. So sending it out=20 now.
 
The solution I would suggest is a new = header=20
       &nbs= p;  =20 Type-Ahead: <time-in-milli-seconds>
header that can be sent on the SET-PARAMS, = GET-PARAMS=20 and RECOGNIZE methods.
 
default is 0 which is todays no buffering = case. If=20 set to some value, the resource is expected to buffer upto=20 <time-in-milliseconds> of audio and use it during the recognize = as a=20 type-ahead buffer. I can see this being a boolean field as well, but = the=20 <time-in-milliseconds> approach is little more=20 flexible.
 
Sarvi

From: Reifenrath, Klaus=20 [mailto:Klaus.Reifenrath@Scansoft.com]
Sent: Tuesday, = August 23,=20 2005 8:41 AM
To: Shanmugham, Saravanan;=20 'dburnett@vocalocity.net'
Cc:=20 'speechsc@ietf.org'
Subject: Problem with DTMF type-ahead=20

The MRCP and MRCPv2 specifications = define how=20 DTMF input should be handled: DTMF input is collected after the = RECOGNIZE=20 request is received until a term-char or timeout is reached. Then a = result=20 or no-match is returned based on any active DTMF grammars. The = problem is=20 there can be a significant amount of time between when one result is = processed by the application and the next grammar is activated. = During that=20 time any DTMF input received will be lost. Such DTMF type-ahead is = common=20 for frequent users of IVR systems, and buffering that type ahead is = required=20 by VoiceXML 2.0 (see section 4.1.8).=20 Can this requirement of VoiceXML = be=20 implemented using MRCP (assuming that the media source CANNOT buffer = DTMF)?=20 If so, how is it done?

Thanks,
Klaus=20

------_=_NextPart_001_01C5A83F.6347157D-- --===============0272124757== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============0272124757==-- From speechsc-bounces@ietf.org Wed Aug 24 02:15:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7oXn-0000XD-OV; Wed, 24 Aug 2005 02:15:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7oXm-0000X7-3x for speechsc@megatron.ietf.org; Wed, 24 Aug 2005 02:15:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16690 for ; Wed, 24 Aug 2005 02:15:22 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7oXw-0003Nk-UQ for speechsc@ietf.org; Wed, 24 Aug 2005 02:15:37 -0400 Received: from ATLANTIS.Brooktrout.com (oceans11.brooktrout.com [204.176.75.121]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j7O6ENiP027615 for ; Wed, 24 Aug 2005 02:14:25 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead Date: Wed, 24 Aug 2005 02:14:19 -0400 Message-ID: <330A23D8336C0346B5C1A5BB19666647E06607@ATLANTIS.Brooktrout.com> Thread-Topic: [Speechsc] RE: Problem with DTMF type-ahead Thread-Index: AcWoO0FVkK5nyeW4Sn2qclBDDIBrlwANxhgg From: "Eric Burger" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: quoted-printable X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org [not as chair] I can see something like "Type-Ahead" for SET/GET-PARAMS, which sets a global digit buffer. I would suggest a more descriptive name, like DTMF-Buffer-Time. That said, I don't see it working for the RECOGNIZE method. The speech resource needs to know *before* the RECOGNIZE request that it needs to buffer DTMF. If it comes in with the RECOGNIZE request, it will be too late. For example: SET-PARAMS DTMF-Buffer-Time: 10000 ... RECOGNIZE DTMF-Buffer-Time: 20000 ... The sensible per-RECOGNIZE attribute is to flush the buffer. While one might be tempted to say "DTMF-Buffer-Time: 0" means flush the buffer, I am sure someone will try to use it with a non-zero value. I would offer we use a different attribute to indicate flushing the buffer before recognition, like "Flush-DTMF: true". -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Corby Anderson Sent: Tuesday, August 23, 2005 7:34 PM To: speechsc@ietf.org Subject: Re: [Speechsc] RE: Problem with DTMF type-ahead I prefer the flexible "Type-Ahead: " approach. =20 This would be useful for implementing vxml listen states that happen=20 after data tags. If a data fetch takes longer than several seconds, you might not want to play dtmf that is older than some limit. Corby Anderson Tellme Networks, Inc. Shanmugham, Saravanan wrote: > Are we assuming then that this is only limited to DTMF type-ahead and=20 > is not speak ahead as well? > =20 > Sarvi > > ------------------------------------------------------------------------ > *From:* Jeff Haynie [mailto:jhaynie@vocalocity.net] > *Sent:* Tuesday, August 23, 2005 3:20 PM > *To:* Shanmugham, Saravanan; Reifenrath, Klaus; > dburnett@vocalocity.net > *Cc:* speechsc@ietf.org > *Subject:* RE: [Speechsc] RE: Problem with DTMF type-ahead > > It would seem like we're not trying to buffer audio (generally) > but only the DIGIT values themselves.=20 > > It would seem better to just be a header such as: > =20 > DTMF-Buffer: > =20 > instead. > =20 > Jeff > > ------------------------------------------------------------------------ > *From:* speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] *On Behalf Of *Shanmugham, > Saravanan > *Sent:* Tuesday, August 23, 2005 4:59 PM > *To:* Reifenrath, Klaus; dburnett@vocalocity.net > *Cc:* speechsc@ietf.org > *Subject:* [Speechsc] RE: Problem with DTMF type-ahead > > =20 > I had typed this response out earlier but wanted to see if there > was any support for this capability. So sending it out now. > =20 > The solution I would suggest is a new header > Type-Ahead: > header that can be sent on the SET-PARAMS, GET-PARAMS and > RECOGNIZE methods. > =20 > default is 0 which is todays no buffering case. If set to some > value, the resource is expected to buffer upto > of audio and use it during the recognize as > a type-ahead buffer. I can see this being a boolean field as well, > but the approach is little more flexible. > =20 > Sarvi > > ------------------------------------------------------------------------ > *From:* Reifenrath, Klaus [mailto:Klaus.Reifenrath@Scansoft.com] > *Sent:* Tuesday, August 23, 2005 8:41 AM > *To:* Shanmugham, Saravanan; 'dburnett@vocalocity.net' > *Cc:* 'speechsc@ietf.org' > *Subject:* Problem with DTMF type-ahead > > The MRCP and MRCPv2 specifications define how DTMF input > should be handled: DTMF input is collected after the RECOGNIZE > request is received until a term-char or timeout is reached. > Then a result or no-match is returned based on any active DTMF > grammars. The problem is there can be a significant amount of > time between when one result is processed by the application > and the next grammar is activated. During that time any DTMF > input received will be lost. Such DTMF type-ahead is common > for frequent users of IVR systems, and buffering that type > ahead is required by VoiceXML 2.0 (see section 4.1.8). Can > this requirement of VoiceXML be implemented using MRCP > (assuming that the media source CANNOT buffer DTMF)? If so, > how is it done? > > Thanks, > Klaus > >----------------------------------------------------------------------- - > >_______________________________________________ >Speechsc mailing list >Speechsc@ietf.org >https://www1.ietf.org/mailman/listinfo/speechsc > =20 > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Aug 24 02:47:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7p2n-0001Yi-5x; Wed, 24 Aug 2005 02:47:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7p2k-0001Yd-TD for speechsc@megatron.ietf.org; Wed, 24 Aug 2005 02:47:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02675 for ; Wed, 24 Aug 2005 02:47:26 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7p31-0004LC-CK for speechsc@ietf.org; Wed, 24 Aug 2005 02:47:43 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 23 Aug 2005 23:47:17 -0700 Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j7O6l9Z5002896; Tue, 23 Aug 2005 23:47:12 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead Date: Tue, 23 Aug 2005 23:43:38 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C2C4253@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] RE: Problem with DTMF type-ahead Thread-Index: AcWoO0FVkK5nyeW4Sn2qclBDDIBrlwANxhggAAD+NRA= From: "Shanmugham, Saravanan" To: "Eric Burger" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org The idea of being able to send it opn the RECOGNIZE is to reduce the time and not increase it.=20 By default, the value is 0. When you do a SET-PARAMS and set it to say 10000 it sets the buffering at the server to 10 seconds. This does not mean that every RECOGNIZE should use this entire 10s of buffer. On an individual RECOGNIZE method basis the client should be able to use 0 - 10s of that buffer. This would be the last X seconds of the buffer before the RECOGNIZE method is recieved the rest would be discarded. Achieves more flexibility than plain flushing true or false. Sarvi -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Eric Burger Sent: Tuesday, August 23, 2005 11:14 PM To: speechsc@ietf.org Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead =20 [not as chair] =20 I can see something like "Type-Ahead" for SET/GET-PARAMS,=20 which sets a global digit buffer. I would suggest a more=20 descriptive name, like DTMF-Buffer-Time. =20 That said, I don't see it working for the RECOGNIZE=20 method. The speech resource needs to know *before* the=20 RECOGNIZE request that it needs to buffer DTMF. If it=20 comes in with the RECOGNIZE request, it will be too late. =20 For example: =20 SET-PARAMS DTMF-Buffer-Time: 10000 ... =20 =20 RECOGNIZE DTMF-Buffer-Time: 20000 ... =20 =20 =20 The sensible per-RECOGNIZE attribute is to flush the=20 buffer. While one might be tempted to say=20 "DTMF-Buffer-Time: 0" means flush the buffer, I am sure=20 someone will try to use it with a non-zero value. I would=20 offer we use a different attribute to indicate flushing=20 the buffer before recognition, like "Flush-DTMF: true". =20 -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Corby Anderson Sent: Tuesday, August 23, 2005 7:34 PM To: speechsc@ietf.org Subject: Re: [Speechsc] RE: Problem with DTMF type-ahead =20 I prefer the flexible "Type-Ahead: "=20 approach. =20 This would be useful for implementing vxml listen states=20 that happen after data tags. If a data fetch takes longer=20 than several seconds, you =20 might not want to play dtmf that is older than some limit. =20 Corby Anderson Tellme Networks, Inc. =20 Shanmugham, Saravanan wrote: =20 > Are we assuming then that this is only limited to DTMF=20 type-ahead and=20 > is not speak ahead as well? > =20 > Sarvi > > ----------------------------------------------------------- ------------- > *From:* Jeff Haynie [mailto:jhaynie@vocalocity.net] > *Sent:* Tuesday, August 23, 2005 3:20 PM > *To:* Shanmugham, Saravanan; Reifenrath, Klaus; > dburnett@vocalocity.net > *Cc:* speechsc@ietf.org > *Subject:* RE: [Speechsc] RE: Problem with DTMF type-ahead > > It would seem like we're not trying to buffer audio=20 (generally) > but only the DIGIT values themselves.=20 > > It would seem better to just be a header such as: > =20 > DTMF-Buffer: > =20 > instead. > =20 > Jeff > > ----------------------------------------------------------- ------------- > *From:* speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] *On Behalf Of *Shanmugham, > Saravanan > *Sent:* Tuesday, August 23, 2005 4:59 PM > *To:* Reifenrath, Klaus; dburnett@vocalocity.net > *Cc:* speechsc@ietf.org > *Subject:* [Speechsc] RE: Problem with DTMF type-ahead > > =20 > I had typed this response out earlier but wanted to=20 see if there > was any support for this capability. So sending it out now. > =20 > The solution I would suggest is a new header > Type-Ahead: > header that can be sent on the SET-PARAMS, GET-PARAMS and > RECOGNIZE methods. > =20 > default is 0 which is todays no buffering case. If=20 set to some > value, the resource is expected to buffer upto > of audio and use it during=20 the recognize as > a type-ahead buffer. I can see this being a boolean=20 field as well, > but the approach is little=20 more flexible. > =20 > Sarvi > > ----------------------------------------------------------- ------------- > *From:* Reifenrath, Klaus [mailto:Klaus.Reifenrath@Scansoft.com] > *Sent:* Tuesday, August 23, 2005 8:41 AM > *To:* Shanmugham, Saravanan; 'dburnett@vocalocity.net' > *Cc:* 'speechsc@ietf.org' > *Subject:* Problem with DTMF type-ahead > > The MRCP and MRCPv2 specifications define how DTMF input > should be handled: DTMF input is collected after=20 the RECOGNIZE > request is received until a term-char or timeout=20 is reached. > Then a result or no-match is returned based on=20 any active DTMF > grammars. The problem is there can be a=20 significant amount of > time between when one result is processed by the=20 application > and the next grammar is activated. During that=20 time any DTMF > input received will be lost. Such DTMF=20 type-ahead is common > for frequent users of IVR systems, and buffering=20 that type > ahead is required by VoiceXML 2.0 (see section=20 4.1.8). Can > this requirement of VoiceXML be implemented using MRCP > (assuming that the media source CANNOT buffer=20 DTMF)? If so, > how is it done? > > Thanks, > Klaus > >---------------------------------------------------------- ------------- - > >_______________________________________________ >Speechsc mailing list >Speechsc@ietf.org >https://www1.ietf.org/mailman/listinfo/speechsc > =20 > =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Aug 24 05:52:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7rw8-00066j-GI; Wed, 24 Aug 2005 05:52:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7rw7-00064P-1a for speechsc@megatron.ietf.org; Wed, 24 Aug 2005 05:52:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10206 for ; Wed, 24 Aug 2005 05:52:44 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7rwO-0001kb-8M for speechsc@ietf.org; Wed, 24 Aug 2005 05:53:05 -0400 Received: from daburkewxp (s142-007.psd.vodafone.ie [213.233.142.7]) by mail.voxpilot.com (Postfix) with ESMTP id A9BCE214041; Wed, 24 Aug 2005 09:52:24 +0000 (GMT) Message-ID: <00f201c5a891$8853ba40$a0d3fd0a@db01.voxpilot.com> From: "Dave Burke" To: "Shanmugham, Saravanan" , "Eric Burger" , References: <03772D1EC8DE624A863058C75874A75C2C4253@vtg-um-e2k6.sj21ad.cisco.com> Subject: Re: [Speechsc] RE: Problem with DTMF type-ahead Date: Wed, 24 Aug 2005 10:52:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Content-Transfer-Encoding: 7bit Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Sounds like a lot of dials to play with: What is the use-case warranting the extra complexity for overriding the SET-PARAMed buffer length on a per RECOGNIZE? The two capabilities that you want (IMO) are: 1. Configuration: How long is the buffer? 2. Action: Flush buffer For configuration, I'd rather see a SET-PARAMs but with a non-zero default - say 10 seconds (2 x default inter-digit time). For flushing, I'd rather see a boolean header on RECOGNIZE for simplicity. That way, out-of-the-box, easy things are easy and harder things are still possible... I don't like the term flush. Is one flushing the DTMF into the recognizer or out into the ether(net)? Hence why I suggested Clear-DTMF-Buffer. Dave ----- Original Message ----- From: "Shanmugham, Saravanan" To: "Eric Burger" ; Sent: Wednesday, August 24, 2005 7:43 AM Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead The idea of being able to send it opn the RECOGNIZE is to reduce the time and not increase it. By default, the value is 0. When you do a SET-PARAMS and set it to say 10000 it sets the buffering at the server to 10 seconds. This does not mean that every RECOGNIZE should use this entire 10s of buffer. On an individual RECOGNIZE method basis the client should be able to use 0 - 10s of that buffer. This would be the last X seconds of the buffer before the RECOGNIZE method is recieved the rest would be discarded. Achieves more flexibility than plain flushing true or false. Sarvi -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Eric Burger Sent: Tuesday, August 23, 2005 11:14 PM To: speechsc@ietf.org Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead [not as chair] I can see something like "Type-Ahead" for SET/GET-PARAMS, which sets a global digit buffer. I would suggest a more descriptive name, like DTMF-Buffer-Time. That said, I don't see it working for the RECOGNIZE method. The speech resource needs to know *before* the RECOGNIZE request that it needs to buffer DTMF. If it comes in with the RECOGNIZE request, it will be too late. For example: SET-PARAMS DTMF-Buffer-Time: 10000 ... RECOGNIZE DTMF-Buffer-Time: 20000 ... The sensible per-RECOGNIZE attribute is to flush the buffer. While one might be tempted to say "DTMF-Buffer-Time: 0" means flush the buffer, I am sure someone will try to use it with a non-zero value. I would offer we use a different attribute to indicate flushing the buffer before recognition, like "Flush-DTMF: true". -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Corby Anderson Sent: Tuesday, August 23, 2005 7:34 PM To: speechsc@ietf.org Subject: Re: [Speechsc] RE: Problem with DTMF type-ahead I prefer the flexible "Type-Ahead: " approach. This would be useful for implementing vxml listen states that happen after data tags. If a data fetch takes longer than several seconds, you might not want to play dtmf that is older than some limit. Corby Anderson Tellme Networks, Inc. Shanmugham, Saravanan wrote: > Are we assuming then that this is only limited to DTMF type-ahead and > is not speak ahead as well? > > Sarvi > > ----------------------------------------------------------- ------------- > *From:* Jeff Haynie [mailto:jhaynie@vocalocity.net] > *Sent:* Tuesday, August 23, 2005 3:20 PM > *To:* Shanmugham, Saravanan; Reifenrath, Klaus; > dburnett@vocalocity.net > *Cc:* speechsc@ietf.org > *Subject:* RE: [Speechsc] RE: Problem with DTMF type-ahead > > It would seem like we're not trying to buffer audio (generally) > but only the DIGIT values themselves. > > It would seem better to just be a header such as: > > DTMF-Buffer: > > instead. > > Jeff > > ----------------------------------------------------------- ------------- > *From:* speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] *On Behalf Of *Shanmugham, > Saravanan > *Sent:* Tuesday, August 23, 2005 4:59 PM > *To:* Reifenrath, Klaus; dburnett@vocalocity.net > *Cc:* speechsc@ietf.org > *Subject:* [Speechsc] RE: Problem with DTMF type-ahead > > > I had typed this response out earlier but wanted to see if there > was any support for this capability. So sending it out now. > > The solution I would suggest is a new header > Type-Ahead: > header that can be sent on the SET-PARAMS, GET-PARAMS and > RECOGNIZE methods. > > default is 0 which is todays no buffering case. If set to some > value, the resource is expected to buffer upto > of audio and use it during the recognize as > a type-ahead buffer. I can see this being a boolean field as well, > but the approach is little more flexible. > > Sarvi > > ----------------------------------------------------------- ------------- > *From:* Reifenrath, Klaus [mailto:Klaus.Reifenrath@Scansoft.com] > *Sent:* Tuesday, August 23, 2005 8:41 AM > *To:* Shanmugham, Saravanan; 'dburnett@vocalocity.net' > *Cc:* 'speechsc@ietf.org' > *Subject:* Problem with DTMF type-ahead > > The MRCP and MRCPv2 specifications define how DTMF input > should be handled: DTMF input is collected after the RECOGNIZE > request is received until a term-char or timeout is reached. > Then a result or no-match is returned based on any active DTMF > grammars. The problem is there can be a significant amount of > time between when one result is processed by the application > and the next grammar is activated. During that time any DTMF > input received will be lost. Such DTMF type-ahead is common > for frequent users of IVR systems, and buffering that type > ahead is required by VoiceXML 2.0 (see section 4.1.8). Can > this requirement of VoiceXML be implemented using MRCP > (assuming that the media source CANNOT buffer DTMF)? If so, > how is it done? > > Thanks, > Klaus > >---------------------------------------------------------- ------------- - > >_______________________________________________ >Speechsc mailing list >Speechsc@ietf.org >https://www1.ietf.org/mailman/listinfo/speechsc > > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Aug 24 07:36:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7tYY-0002qV-Na; Wed, 24 Aug 2005 07:36:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7tYX-0002qQ-9l for speechsc@megatron.ietf.org; Wed, 24 Aug 2005 07:36:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14393 for ; Wed, 24 Aug 2005 07:36:32 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7tYq-0004hr-Dm for speechsc@ietf.org; Wed, 24 Aug 2005 07:36:52 -0400 Received: from ATLANTIS.Brooktrout.com (oceans11.brooktrout.com [204.176.75.121]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j7OBVI3C012406; Wed, 24 Aug 2005 07:31:18 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead Date: Wed, 24 Aug 2005 07:31:13 -0400 Message-ID: <330A23D8336C0346B5C1A5BB19666647E066A1@ATLANTIS.Brooktrout.com> Thread-Topic: [Speechsc] RE: Problem with DTMF type-ahead Thread-Index: AcWokY2nOWUMZ0/RTlajUyiwMSDepAADFCrA From: "Eric Burger" To: "Dave Burke" , "Shanmugham, Saravanan" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Content-Transfer-Encoding: quoted-printable Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org [not as chair] We went through this whole discussion for KPML. No one ever had a use case for "keep the last x seconds". In fact, one either buffered digits or flushed them. If you have an 8,000 port media engine, with one hour call times, and continuous digit entry without the digits ever getting off the queue, and the digit entry is computer generated (i.e., as fast as possible), you need: (8,000 ports) * (3,600,000ms/port) / (60ms / digit) =3D 480MB I would offer that if you have an 8,000 port media processing device, less than half a gigabyte for digit buffering is nothing. In English, that means that you can realistically have infinite digit buffering. That makes the protocol MUCH easier, interoperation MUCH easier, and implementation MUCH easier. [really not as chair] As for the term, I didn't think anyone had an alternative interpretation of the term "flush". However, I suppose "clear" is OK. -----Original Message----- From: Dave Burke [mailto:david.burke@voxpilot.com]=20 Sent: Wednesday, August 24, 2005 5:52 AM To: Shanmugham, Saravanan; Eric Burger; speechsc@ietf.org Subject: Re: [Speechsc] RE: Problem with DTMF type-ahead Sounds like a lot of dials to play with: What is the use-case warranting the=20 extra complexity for overriding the SET-PARAMed buffer length on a per=20 RECOGNIZE? The two capabilities that you want (IMO) are: 1. Configuration: How long is the buffer? 2. Action: Flush buffer For configuration, I'd rather see a SET-PARAMs but with a non-zero default -=20 say 10 seconds (2 x default inter-digit time). For flushing, I'd rather see=20 a boolean header on RECOGNIZE for simplicity. That way, out-of-the-box, easy=20 things are easy and harder things are still possible... I don't like the term flush. Is one flushing the DTMF into the recognizer or=20 out into the ether(net)? Hence why I suggested Clear-DTMF-Buffer. Dave ----- Original Message -----=20 From: "Shanmugham, Saravanan" To: "Eric Burger" ; Sent: Wednesday, August 24, 2005 7:43 AM Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead The idea of being able to send it opn the RECOGNIZE is to reduce the time and not increase it. By default, the value is 0. When you do a SET-PARAMS and set it to say 10000 it sets the buffering at the server to 10 seconds. This does not mean that every RECOGNIZE should use this entire 10s of buffer. On an individual RECOGNIZE method basis the client should be able to use 0 - 10s of that buffer. This would be the last X seconds of the buffer before the RECOGNIZE method is recieved the rest would be discarded. Achieves more flexibility than plain flushing true or false. Sarvi -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Eric Burger Sent: Tuesday, August 23, 2005 11:14 PM To: speechsc@ietf.org Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead [not as chair] I can see something like "Type-Ahead" for SET/GET-PARAMS, which sets a global digit buffer. I would suggest a more descriptive name, like DTMF-Buffer-Time. That said, I don't see it working for the RECOGNIZE method. The speech resource needs to know *before* the RECOGNIZE request that it needs to buffer DTMF. If it comes in with the RECOGNIZE request, it will be too late. For example: SET-PARAMS DTMF-Buffer-Time: 10000 ... RECOGNIZE DTMF-Buffer-Time: 20000 ... The sensible per-RECOGNIZE attribute is to flush the buffer. While one might be tempted to say "DTMF-Buffer-Time: 0" means flush the buffer, I am sure someone will try to use it with a non-zero value. I would offer we use a different attribute to indicate flushing the buffer before recognition, like "Flush-DTMF: true". -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Corby Anderson Sent: Tuesday, August 23, 2005 7:34 PM To: speechsc@ietf.org Subject: Re: [Speechsc] RE: Problem with DTMF type-ahead I prefer the flexible "Type-Ahead: " approach. This would be useful for implementing vxml listen states that happen after data tags. If a data fetch takes longer than several seconds, you might not want to play dtmf that is older than some limit. Corby Anderson Tellme Networks, Inc. Shanmugham, Saravanan wrote: > Are we assuming then that this is only limited to DTMF type-ahead and > is not speak ahead as well? > > Sarvi > > ----------------------------------------------------------- ------------- > *From:* Jeff Haynie [mailto:jhaynie@vocalocity.net] > *Sent:* Tuesday, August 23, 2005 3:20 PM > *To:* Shanmugham, Saravanan; Reifenrath, Klaus; > dburnett@vocalocity.net > *Cc:* speechsc@ietf.org > *Subject:* RE: [Speechsc] RE: Problem with DTMF type-ahead > > It would seem like we're not trying to buffer audio (generally) > but only the DIGIT values themselves. > > It would seem better to just be a header such as: > > DTMF-Buffer: > > instead. > > Jeff > > ----------------------------------------------------------- ------------- > *From:* speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] *On Behalf Of *Shanmugham, > Saravanan > *Sent:* Tuesday, August 23, 2005 4:59 PM > *To:* Reifenrath, Klaus; dburnett@vocalocity.net > *Cc:* speechsc@ietf.org > *Subject:* [Speechsc] RE: Problem with DTMF type-ahead > > > I had typed this response out earlier but wanted to see if there > was any support for this capability. So sending it out now. > > The solution I would suggest is a new header > Type-Ahead: > header that can be sent on the SET-PARAMS, GET-PARAMS and > RECOGNIZE methods. > > default is 0 which is todays no buffering case. If set to some > value, the resource is expected to buffer upto > of audio and use it during the recognize as > a type-ahead buffer. I can see this being a boolean field as well, > but the approach is little more flexible. > > Sarvi > > ----------------------------------------------------------- ------------- > *From:* Reifenrath, Klaus [mailto:Klaus.Reifenrath@Scansoft.com] > *Sent:* Tuesday, August 23, 2005 8:41 AM > *To:* Shanmugham, Saravanan; 'dburnett@vocalocity.net' > *Cc:* 'speechsc@ietf.org' > *Subject:* Problem with DTMF type-ahead > > The MRCP and MRCPv2 specifications define how DTMF input > should be handled: DTMF input is collected after the RECOGNIZE > request is received until a term-char or timeout is reached. > Then a result or no-match is returned based on any active DTMF > grammars. The problem is there can be a significant amount of > time between when one result is processed by the application > and the next grammar is activated. During that time any DTMF > input received will be lost. Such DTMF type-ahead is common > for frequent users of IVR systems, and buffering that type > ahead is required by VoiceXML 2.0 (see section 4.1.8). Can > this requirement of VoiceXML be implemented using MRCP > (assuming that the media source CANNOT buffer DTMF)? If so, > how is it done? > > Thanks, > Klaus > >---------------------------------------------------------- ------------- - > >_______________________________________________ >Speechsc mailing list >Speechsc@ietf.org >https://www1.ietf.org/mailman/listinfo/speechsc > > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Aug 24 13:46:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zKW-0006v2-4j; Wed, 24 Aug 2005 13:46:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zKU-0006tt-2N for speechsc@megatron.ietf.org; Wed, 24 Aug 2005 13:46:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07932 for ; Wed, 24 Aug 2005 13:46:24 -0400 (EDT) Received: from mail.voicegenie.com ([205.150.90.87] helo=voicegenie.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7zKn-00018c-Vj for speechsc@ietf.org; Wed, 24 Aug 2005 13:46:48 -0400 Received: from [205.150.90.65] (parrot.voicegenie.com [205.150.90.65]) by voicegenie.com (8.11.6+Sun/8.9.3) with ESMTP id j7OHk6Q27882; Wed, 24 Aug 2005 13:46:06 -0400 (EDT) Message-ID: <430CB25D.3030402@voicegenie.com> Date: Wed, 24 Aug 2005 13:46:05 -0400 From: Andrew Wahbe Organization: VoiceGenie Technologies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Shanmugham, Saravanan" Subject: Re: [Speechsc] Recognition Completion-Cause Codes 003 and 008 revisited References: <03772D1EC8DE624A863058C75874A75C2C41CA@vtg-um-e2k6.sj21ad.cisco.com> In-Reply-To: <03772D1EC8DE624A863058C75874A75C2C41CA@vtg-um-e2k6.sj21ad.cisco.com> Content-Type: multipart/mixed; boundary="------------000607080108070700050700" X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --------------000607080108070700050700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The problem with re-using one of the redundant completion-cause codes is that we changed the meaning of the other one -- it has been limited to cases where we have a match. Now neither of the completion-cause codes map to VoiceXML maxspeechtimeout -- there was a recognition-timeout and there was no match. I think we still need a code for this case. The explanation for the hotword completion-cause code doesn't make sense or I'm missing something. You're saying that the recognition would still continue when the timer fires even when there is no match. This makes sense for hotword recognition, but if recognition continues, then why do you need a completion-cause code... recognition has not completed. Actually, now that I think about it, in the context of hotword recognition, the recognition-timeout seems to be identical to the hotword-max-duration. Is this accurate? Andrew Wahbe VoiceGenie Technologies Shanmugham, Saravanan wrote: >I was going to remove Recognition-Timeout based on the thread on the >confusion between this cause and max-speech-timeout etc. > >But it was agreed we need a timeout capability for HotWord Recognition >based ona separate thread. > >In the hotword case, none of the timeout desciptions match the way >timeout happens in hotword recognition. Since there, even if the words >spoken until that point did not match any of the hotwords, the >recognition would still continue. Hence a separate completion code for >hotword recognition timeout was needed. And I have used 03 for that use >case. > >Sarvi > > -----Original Message----- > From: speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] On Behalf Of Andrew Wahbe > Sent: Tuesday, August 23, 2005 7:34 AM > To: speechsc@ietf.org > Subject: [Speechsc] Recognition Completion-Cause Codes 003 > and 008 revisited > > A few weeks ago, there was an extensive discussion about > the recognition completion-cause codes for cases where > recognition-timers fire. There seemed to be two codes, 003 > and 008, that meant the same thing -- the recognition was > aborted due to the recognition-timer firing. This case > maps to the maxspeechtimeout event in VoiceXML. > > A lot of hypothesizing was done to try and figure out what > the difference between the codes was. After some > discussion it seems we ended up with no codes that map to > maxspeechtimeout in VoiceXML (i.e. > the recognition was aborted because of recognition-timeout > and there is no match). > > I think things would be set right if 003 was changed from: > > | 003 | recognition-timeout | RECOGNIZE in hotword > mode | > | | | completed without a > match due to | > | | | a > recognition-timeout | > > to: > > | 003 | recognition-timeout | RECOGNIZE completed > without a | > | | | match due to a > | > | | | recognition-timeout > | > > > I am not sure why a special code is needed for this timer > firing in hotword mode. Am I missing something? > > Andrew Wahbe > VoiceGenie Technologies > > > > > --------------000607080108070700050700 Content-Type: text/x-vcard; charset=utf-8; name="awahbe.vcf" Content-Disposition: attachment; filename="awahbe.vcf" Content-Transfer-Encoding: 7bit begin:vcard fn:Andrew Wahbe n:Wahbe;Andrew org:VoiceGenie Technologies INC.;Multimodal and Development Tools adr:8th Floor;;1120 Finch Avenue W.;Toronto;ON;M3J 3H7;Canada email;internet:awahbe@voicegenie.com title:Technical Manager tel;work:(416) 736-0905 ext. 258 tel;fax:(416) 736-1551 x-mozilla-html:TRUE url:http://www.voicegenie.com version:2.1 end:vcard --------------000607080108070700050700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --------------000607080108070700050700-- From speechsc-bounces@ietf.org Wed Aug 24 14:01:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zYy-0003Ol-7D; Wed, 24 Aug 2005 14:01:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zYv-0003OS-QG for speechsc@megatron.ietf.org; Wed, 24 Aug 2005 14:01:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08836 for ; Wed, 24 Aug 2005 14:01:20 -0400 (EDT) Received: from letter.nuance.com ([207.107.210.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7zZH-0001eh-Vt for speechsc@ietf.org; Wed, 24 Aug 2005 14:01:44 -0400 Received: from postcard.nuance.com ([10.3.6.20]:23458) by letter.nuance.com with esmtp id 1E7zYi-0005Pn-2q; Wed, 24 Aug 2005 11:01:08 -0700 Received: from mtb1exch01.nuance.com ([10.3.2.6]) by postcard.nuance.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 24 Aug 2005 14:01:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead Date: Wed, 24 Aug 2005 14:01:01 -0400 Message-ID: <7DE7C4EF3B7C8B4B82955191378290D803228367@mtb1exch01.nuance.com> Thread-Topic: [Speechsc] RE: Problem with DTMF type-ahead Thread-Index: AcWn+6tjuWWuWeMTTXKPwEhMTCB1xgABfb3wAAu+kHAAAF9z8AAoeWPA From: "Pierre Forgues" To: "Shanmugham, Saravanan" , "Jeff Haynie" , "Klaus Reifenrath" , X-OriginalArrivalTime: 24 Aug 2005 18:01:00.0524 (UTC) FILETIME=[C9184AC0:01C5A8D5] X-FromHost: postcard.nuance.com [10.3.6.20]:23458 Lines: 568 X-Spam-Score: 0.3 (/) X-Scan-Signature: 08868c2bcdb53bddcb7cc7e7cf96b038 Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1285629604==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1285629604== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A8D5.C9C6C22A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A8D5.C9C6C22A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Let's limit the capability to DTMF type-ahead. I've heard of power users, but I don't think it is feasible or desirable to talk about people speaking before the beginning of prompts. This would add unnecessary complexity in my opinion. =20 I like the terminology of "clearing" a buffer rather than flushing. =20 Pierre =20 ________________________________ From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Shanmugham, Saravanan Sent: Tuesday, August 23, 2005 6:31 PM To: Jeff Haynie; Klaus Reifenrath; dburnett@vocalocity.net Cc: speechsc@ietf.org Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead=20 =20 Are we assuming then that this is only limited to DTMF type-ahead and is not speak ahead as well? =20 Sarvi =20 =09 ________________________________ From: Jeff Haynie [mailto:jhaynie@vocalocity.net]=20 Sent: Tuesday, August 23, 2005 3:20 PM To: Shanmugham, Saravanan; Reifenrath, Klaus; dburnett@vocalocity.net Cc: speechsc@ietf.org Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead=20 It would seem like we're not trying to buffer audio (generally) but only the DIGIT values themselves. =20 =09 It would seem better to just be a header such as: =20 DTMF-Buffer: =20 instead. =20 Jeff =20 =09 ________________________________ From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Shanmugham, Saravanan Sent: Tuesday, August 23, 2005 4:59 PM To: Reifenrath, Klaus; dburnett@vocalocity.net Cc: speechsc@ietf.org Subject: [Speechsc] RE: Problem with DTMF type-ahead=20 =20 I had typed this response out earlier but wanted to see if there was any support for this capability. So sending it out now. =20 The solution I would suggest is a new header=20 Type-Ahead: =20 header that can be sent on the SET-PARAMS, GET-PARAMS and RECOGNIZE methods. =20 default is 0 which is todays no buffering case. If set to some value, the resource is expected to buffer upto of audio and use it during the recognize as a type-ahead buffer. I can see this being a boolean field as well, but the approach is little more flexible. =20 Sarvi =20 =09 ________________________________ From: Reifenrath, Klaus [mailto:Klaus.Reifenrath@Scansoft.com]=20 Sent: Tuesday, August 23, 2005 8:41 AM To: Shanmugham, Saravanan; 'dburnett@vocalocity.net' Cc: 'speechsc@ietf.org' Subject: Problem with DTMF type-ahead=20 The MRCP and MRCPv2 specifications define how DTMF input should be handled: DTMF input is collected after the RECOGNIZE request is received until a term-char or timeout is reached. Then a result or no-match is returned based on any active DTMF grammars. The problem is there can be a significant amount of time between when one result is processed by the application and the next grammar is activated. During that time any DTMF input received will be lost. Such DTMF type-ahead is common for frequent users of IVR systems, and buffering that type ahead is required by VoiceXML 2.0 (see section 4.1.8). Can this requirement of VoiceXML be implemented using MRCP (assuming that the media source CANNOT buffer DTMF)? If so, how is it done?=20 Thanks, Klaus=20 ------_=_NextPart_001_01C5A8D5.C9C6C22A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Problem with DTMF type-ahead

Let’s limit the capability to = DTMF type-ahead.  I’ve heard of power users, but I don’t = think it is feasible or desirable to talk about people speaking before the = beginning of prompts.  This would add unnecessary complexity in my = opinion.

 

I like the terminology of = “clearing” a buffer rather than flushing.

 

Pierre

 

From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Shanmugham, = Saravanan
Sent: Tuesday, August 23, = 2005 6:31 PM
To: Jeff Haynie; = Klaus Reifenrath; = dburnett@vocalocity.net
Cc: speechsc@ietf.org
Subject: RE: [Speechsc] = RE: Problem with DTMF type-ahead

 

Are we assuming then that this is only limited to DTMF type-ahead and is not speak ahead as = well?

 

Sarvi

 

From: Jeff Haynie [mailto:jhaynie@vocalocity.net]
Sent: Tuesday, August 23, = 2005 3:20 PM
To: Shanmugham, = Saravanan; Reifenrath, Klaus; dburnett@vocalocity.net
Cc: speechsc@ietf.org
Subject: RE: [Speechsc] = RE: Problem with DTMF type-ahead

It would seem like we're not trying = to buffer audio (generally) but only the DIGIT values themselves.  =


It would seem better to just be a header = such as:

 

DTMF-Buffer: = <true|false>

 

instead.

 

Jeff

 

From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Shanmugham, = Saravanan
Sent: Tuesday, August 23, = 2005 4:59 PM
To: Reifenrath, Klaus; dburnett@vocalocity.net
Cc: speechsc@ietf.org
Subject: [Speechsc] RE: = Problem with DTMF type-ahead

 

I had typed this response out = earlier but wanted to see if there was any support for this capability. So sending = it out now.

 

The solution I would suggest is a = new header

      =      Type-Ahead: <time-in-milli-seconds>

header that can be sent on the = SET-PARAMS, GET-PARAMS and RECOGNIZE methods.

 

default is 0 which is todays no = buffering case. If set to some value, the resource is expected to buffer upto <time-in-milliseconds> of audio and use it during the recognize as = a type-ahead buffer. I can see this being a boolean field as well, but the <time-in-milliseconds> approach is little more = flexible.

 

Sarvi

 

From: Reifenrath, Klaus [mailto:Klaus.Reifenrath@Scansoft.com]
Sent: Tuesday, August 23, = 2005 8:41 AM
To: Shanmugham, = Saravanan; 'dburnett@vocalocity.net'
Cc: = 'speechsc@ietf.org'
Subject: Problem with = DTMF type-ahead

The MRCP and MRCPv2 specifications define how DTMF input should be handled: = DTMF input is collected after the RECOGNIZE request is received until a = term-char or timeout is reached. Then a result or no-match is returned based on any = active DTMF grammars. The problem is there can be a significant amount of time = between when one result is processed by the application and the next grammar is activated. During that time any DTMF input received will be lost. Such = DTMF type-ahead is common for frequent users of IVR systems, and buffering = that type ahead is required by VoiceXML 2.0 (see section 4.1.8). = Can this requirement of VoiceXML be implemented using MRCP (assuming that the = media source CANNOT buffer DTMF)? If so, how is it done? =

Thanks,
Klaus

------_=_NextPart_001_01C5A8D5.C9C6C22A-- --===============1285629604== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============1285629604==-- From speechsc-bounces@ietf.org Wed Aug 24 14:22:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ztP-00034i-JE; Wed, 24 Aug 2005 14:22:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ztN-00031Z-Hf for speechsc@megatron.ietf.org; Wed, 24 Aug 2005 14:22:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09898 for ; Wed, 24 Aug 2005 14:22:28 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7ztj-0002Mp-WE for speechsc@ietf.org; Wed, 24 Aug 2005 14:22:52 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 24 Aug 2005 11:22:20 -0700 Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j7OIM72s017314; Wed, 24 Aug 2005 11:22:16 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead Date: Wed, 24 Aug 2005 11:22:10 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C2C42A9@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] RE: Problem with DTMF type-ahead Thread-Index: AcWokY2nOWUMZ0/RTlajUyiwMSDepAADFCrAAA5tVzA= From: "Shanmugham, Saravanan" To: "Eric Burger" , "Dave Burke" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a4bcf8f67063cac573319207fe3db35 Content-Transfer-Encoding: quoted-printable Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Ok. Lets limit this buffer to digits and not speech.=20 Lets also stick to clear buffer operation in RECOGNIZE method. But should be the buffer size. Settable by the client? Platform specific fixed? Settable client on a per RECOGNIZE basis. Unlimited size may be ok for implementation, but is it practical and what does it mean in actual usage.=20 If the recognizer channel was allocated at the beginning of the call, and at some later point in the call, much later, we do a recognize. Does this mean that any digits pressed since the beginning of the call when the resource was allocated or the previous RECOGNIZE, are used as part of the type-ahead? Sarvi=20 -----Original Message----- From: Eric Burger [mailto:eburger@brooktrout.com]=20 Sent: Wednesday, August 24, 2005 4:31 AM To: Dave Burke; Shanmugham, Saravanan Cc: speechsc@ietf.org Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead =20 [not as chair] We went through this whole discussion for KPML. No one=20 ever had a use case for "keep the last x seconds". In=20 fact, one either buffered digits or flushed them. =20 If you have an 8,000 port media engine, with one hour call=20 times, and continuous digit entry without the digits ever=20 getting off the queue, and the digit entry is computer=20 generated (i.e., as fast as possible), you need: (8,000 ports) * (3,600,000ms/port) / (60ms / digit) =3D 480MB =20 I would offer that if you have an 8,000 port media=20 processing device, less than half a gigabyte for digit=20 buffering is nothing. =20 In English, that means that you can realistically have=20 infinite digit buffering. =20 That makes the protocol MUCH easier, interoperation MUCH=20 easier, and implementation MUCH easier. =20 [really not as chair] As for the term, I didn't think anyone had an alternative=20 interpretation of the term "flush". However, I suppose=20 "clear" is OK. =20 -----Original Message----- From: Dave Burke [mailto:david.burke@voxpilot.com] Sent: Wednesday, August 24, 2005 5:52 AM To: Shanmugham, Saravanan; Eric Burger; speechsc@ietf.org Subject: Re: [Speechsc] RE: Problem with DTMF type-ahead =20 Sounds like a lot of dials to play with: What is the=20 use-case warranting the extra complexity for overriding=20 the SET-PARAMed buffer length on a per RECOGNIZE? =20 The two capabilities that you want (IMO) are: 1. Configuration: How long is the buffer? 2. Action: Flush buffer =20 For configuration, I'd rather see a SET-PARAMs but with a=20 non-zero default - say 10 seconds (2 x default inter-digit=20 time). For flushing, I'd rather see a boolean header on=20 RECOGNIZE for simplicity. That way, out-of-the-box, easy=20 things are easy and harder things are still possible... =20 I don't like the term flush. Is one flushing the DTMF into=20 the recognizer or out into the ether(net)? Hence why I=20 suggested Clear-DTMF-Buffer. =20 Dave =20 ----- Original Message ----- From: "Shanmugham, Saravanan" To: "Eric Burger" ; Sent: Wednesday, August 24, 2005 7:43 AM Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead =20 =20 The idea of being able to send it opn the RECOGNIZE is to=20 reduce the time and not increase it. =20 By default, the value is 0. When you do a SET-PARAMS and=20 set it to say 10000 it sets the buffering at the server to 10 seconds. =20 This does not mean that every RECOGNIZE should use this=20 entire 10s of buffer. On an individual RECOGNIZE method basis the client=20 should be able to use 0 - 10s of that buffer. This would be the last=20 X seconds of the buffer before the RECOGNIZE method is recieved the=20 rest would be discarded. =20 Achieves more flexibility than plain flushing true or false. =20 Sarvi =20 -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Eric Burger Sent: Tuesday, August 23, 2005 11:14 PM To: speechsc@ietf.org Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead =20 [not as chair] =20 I can see something like "Type-Ahead" for SET/GET-PARAMS, which sets a global digit buffer. I would suggest a more descriptive name, like DTMF-Buffer-Time. =20 That said, I don't see it working for the RECOGNIZE method. The speech resource needs to know *before* the RECOGNIZE request that it needs to buffer DTMF. If it comes in with the RECOGNIZE request, it will be too late. =20 For example: =20 SET-PARAMS DTMF-Buffer-Time: 10000 ... =20 =20 RECOGNIZE DTMF-Buffer-Time: 20000 ... =20 =20 =20 The sensible per-RECOGNIZE attribute is to flush the buffer. While one might be tempted to say "DTMF-Buffer-Time: 0" means flush the buffer, I am sure someone will try to use it with a non-zero value. I would offer we use a different attribute to indicate flushing the buffer before recognition, like "Flush-DTMF: true". =20 -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Corby Anderson Sent: Tuesday, August 23, 2005 7:34 PM To: speechsc@ietf.org Subject: Re: [Speechsc] RE: Problem with DTMF type-ahead =20 I prefer the flexible "Type-Ahead: " approach. This would be useful for implementing vxml listen states that happen after data tags. If a data fetch takes longer than several seconds, you =20 might not want to play dtmf that is older than some limit. =20 Corby Anderson Tellme Networks, Inc. =20 Shanmugham, Saravanan wrote: =20 > Are we assuming then that this is only limited to DTMF type-ahead and > is not speak ahead as well? > > Sarvi > > ----------------------------------------------------------- ------------- > *From:* Jeff Haynie [mailto:jhaynie@vocalocity.net] > *Sent:* Tuesday, August 23, 2005 3:20 PM > *To:* Shanmugham, Saravanan; Reifenrath, Klaus; > dburnett@vocalocity.net > *Cc:* speechsc@ietf.org > *Subject:* RE: [Speechsc] RE: Problem with DTMF=20 type-ahead > > It would seem like we're not trying to buffer audio (generally) > but only the DIGIT values themselves. > > It would seem better to just be a header such as: > > DTMF-Buffer: > > instead. > > Jeff > > ----------------------------------------------------------- ------------- > *From:* speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] *On Behalf=20 Of *Shanmugham, > Saravanan > *Sent:* Tuesday, August 23, 2005 4:59 PM > *To:* Reifenrath, Klaus; dburnett@vocalocity.net > *Cc:* speechsc@ietf.org > *Subject:* [Speechsc] RE: Problem with DTMF type-ahead > > > I had typed this response out earlier but wanted to see if there > was any support for this capability. So sending=20 it out now. > > The solution I would suggest is a new header > Type-Ahead: > header that can be sent on the SET-PARAMS,=20 GET-PARAMS and > RECOGNIZE methods. > > default is 0 which is todays no buffering case. If set to some > value, the resource is expected to buffer upto > of audio and use it during the recognize as > a type-ahead buffer. I can see this being a boolean field as well, > but the approach is little more flexible. > > Sarvi > > ----------------------------------------------------------- ------------- > *From:* Reifenrath, Klaus [mailto:Klaus.Reifenrath@Scansoft.com] > *Sent:* Tuesday, August 23, 2005 8:41 AM > *To:* Shanmugham, Saravanan;=20 'dburnett@vocalocity.net' > *Cc:* 'speechsc@ietf.org' > *Subject:* Problem with DTMF type-ahead > > The MRCP and MRCPv2 specifications define=20 how DTMF input > should be handled: DTMF input is collected after the RECOGNIZE > request is received until a term-char or timeout is reached. > Then a result or no-match is returned based on any active DTMF > grammars. The problem is there can be a significant amount of > time between when one result is processed by the application > and the next grammar is activated. During that time any DTMF > input received will be lost. Such DTMF type-ahead is common > for frequent users of IVR systems, and buffering that type > ahead is required by VoiceXML 2.0 (see section 4.1.8). Can > this requirement of VoiceXML be implemented=20 using MRCP > (assuming that the media source CANNOT buffer DTMF)? If so, > how is it done? > > Thanks, > Klaus > >---------------------------------------------------------- ------------- - > >_______________________________________________ >Speechsc mailing list >Speechsc@ietf.org >https://www1.ietf.org/mailman/listinfo/speechsc > > =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Aug 24 14:49:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E80Jg-0003cu-Qt; Wed, 24 Aug 2005 14:49:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E80Je-0003cn-DW for speechsc@megatron.ietf.org; Wed, 24 Aug 2005 14:49:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11119 for ; Wed, 24 Aug 2005 14:49:37 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E80Jo-00039T-Oz for speechsc@ietf.org; Wed, 24 Aug 2005 14:50:01 -0400 Received: from ATLANTIS.Brooktrout.com (oceans11.brooktrout.com [204.176.75.121]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j7OIdYMK007533; Wed, 24 Aug 2005 14:39:34 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead Date: Wed, 24 Aug 2005 14:39:29 -0400 Message-ID: <330A23D8336C0346B5C1A5BB19666647E06A92@ATLANTIS.Brooktrout.com> Thread-Topic: [Speechsc] RE: Problem with DTMF type-ahead Thread-Index: AcWokY2nOWUMZ0/RTlajUyiwMSDepAADFCrAAA5tVzAAAK6aMA== From: "Eric Burger" To: "Shanmugham, Saravanan" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b3349545af520ba354ccdc9e1a03fc1 Content-Transfer-Encoding: quoted-printable Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org [not as chair] I still see no use case for NOT having the buffer go back to the beginning of time. Since there is no need for a limit to the buffer size, why complicate things? Because someone will always come up with a bizarre corner case, KPML does do a circular buffer thing, dropping real old tones, and indicating that old tones were lost. However, even on a memory constrained telephone, that would be hours of digits being entered continuously (i.e., still probably never could happen). Thus, to the question of "Should the client set the buffer size?" the answer is "no". The size is effectively infinite. "Is the size set by the platform?" I would say "no", because there is no reason to. However, if you are ultra paranoid about a DoS attack that runs for a really long time (which in itself is going to be the source of the problem, not that your DTMF buffer overflows), I suppose one could say "yes". My personal opinion is still to just have an infinite buffer size, going back to the last recognition / start of buffering / last flush. -----Original Message----- From: Shanmugham, Saravanan [mailto:sarvi@cisco.com]=20 Sent: Wednesday, August 24, 2005 2:22 PM To: Eric Burger; Dave Burke Cc: speechsc@ietf.org Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead Ok. Lets limit this buffer to digits and not speech.=20 Lets also stick to clear buffer operation in RECOGNIZE method. But should be the buffer size. Settable by the client? Platform specific fixed? Settable client on a per RECOGNIZE basis. Unlimited size may be ok for implementation, but is it practical and what does it mean in actual usage.=20 If the recognizer channel was allocated at the beginning of the call, and at some later point in the call, much later, we do a recognize. Does this mean that any digits pressed since the beginning of the call when the resource was allocated or the previous RECOGNIZE, are used as part of the type-ahead? Sarvi=20 -----Original Message----- From: Eric Burger [mailto:eburger@brooktrout.com]=20 Sent: Wednesday, August 24, 2005 4:31 AM To: Dave Burke; Shanmugham, Saravanan Cc: speechsc@ietf.org Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead =20 [not as chair] We went through this whole discussion for KPML. No one=20 ever had a use case for "keep the last x seconds". In=20 fact, one either buffered digits or flushed them. =20 If you have an 8,000 port media engine, with one hour call=20 times, and continuous digit entry without the digits ever=20 getting off the queue, and the digit entry is computer=20 generated (i.e., as fast as possible), you need: (8,000 ports) * (3,600,000ms/port) / (60ms / digit) =3D 480MB =20 I would offer that if you have an 8,000 port media=20 processing device, less than half a gigabyte for digit=20 buffering is nothing. =20 In English, that means that you can realistically have=20 infinite digit buffering. =20 That makes the protocol MUCH easier, interoperation MUCH=20 easier, and implementation MUCH easier. =20 [really not as chair] As for the term, I didn't think anyone had an alternative=20 interpretation of the term "flush". However, I suppose=20 "clear" is OK. =20 -----Original Message----- From: Dave Burke [mailto:david.burke@voxpilot.com] Sent: Wednesday, August 24, 2005 5:52 AM To: Shanmugham, Saravanan; Eric Burger; speechsc@ietf.org Subject: Re: [Speechsc] RE: Problem with DTMF type-ahead =20 Sounds like a lot of dials to play with: What is the=20 use-case warranting the extra complexity for overriding=20 the SET-PARAMed buffer length on a per RECOGNIZE? =20 The two capabilities that you want (IMO) are: 1. Configuration: How long is the buffer? 2. Action: Flush buffer =20 For configuration, I'd rather see a SET-PARAMs but with a=20 non-zero default - say 10 seconds (2 x default inter-digit=20 time). For flushing, I'd rather see a boolean header on=20 RECOGNIZE for simplicity. That way, out-of-the-box, easy=20 things are easy and harder things are still possible... =20 I don't like the term flush. Is one flushing the DTMF into=20 the recognizer or out into the ether(net)? Hence why I=20 suggested Clear-DTMF-Buffer. =20 Dave =20 ----- Original Message ----- From: "Shanmugham, Saravanan" To: "Eric Burger" ; Sent: Wednesday, August 24, 2005 7:43 AM Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead =20 =20 The idea of being able to send it opn the RECOGNIZE is to=20 reduce the time and not increase it. =20 By default, the value is 0. When you do a SET-PARAMS and=20 set it to say 10000 it sets the buffering at the server to 10 seconds. =20 This does not mean that every RECOGNIZE should use this=20 entire 10s of buffer. On an individual RECOGNIZE method basis the client=20 should be able to use 0 - 10s of that buffer. This would be the last=20 X seconds of the buffer before the RECOGNIZE method is recieved the=20 rest would be discarded. =20 Achieves more flexibility than plain flushing true or false. =20 Sarvi =20 -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Eric Burger Sent: Tuesday, August 23, 2005 11:14 PM To: speechsc@ietf.org Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead =20 [not as chair] =20 I can see something like "Type-Ahead" for SET/GET-PARAMS, which sets a global digit buffer. I would suggest a more descriptive name, like DTMF-Buffer-Time. =20 That said, I don't see it working for the RECOGNIZE method. The speech resource needs to know *before* the RECOGNIZE request that it needs to buffer DTMF. If it comes in with the RECOGNIZE request, it will be too late. =20 For example: =20 SET-PARAMS DTMF-Buffer-Time: 10000 ... =20 =20 RECOGNIZE DTMF-Buffer-Time: 20000 ... =20 =20 =20 The sensible per-RECOGNIZE attribute is to flush the buffer. While one might be tempted to say "DTMF-Buffer-Time: 0" means flush the buffer, I am sure someone will try to use it with a non-zero value. I would offer we use a different attribute to indicate flushing the buffer before recognition, like "Flush-DTMF: true". =20 -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Corby Anderson Sent: Tuesday, August 23, 2005 7:34 PM To: speechsc@ietf.org Subject: Re: [Speechsc] RE: Problem with DTMF type-ahead =20 I prefer the flexible "Type-Ahead: " approach. This would be useful for implementing vxml listen states that happen after data tags. If a data fetch takes longer than several seconds, you =20 might not want to play dtmf that is older than some limit. =20 Corby Anderson Tellme Networks, Inc. =20 Shanmugham, Saravanan wrote: =20 > Are we assuming then that this is only limited to DTMF type-ahead and > is not speak ahead as well? > > Sarvi > > ----------------------------------------------------------- ------------- > *From:* Jeff Haynie [mailto:jhaynie@vocalocity.net] > *Sent:* Tuesday, August 23, 2005 3:20 PM > *To:* Shanmugham, Saravanan; Reifenrath, Klaus; > dburnett@vocalocity.net > *Cc:* speechsc@ietf.org > *Subject:* RE: [Speechsc] RE: Problem with DTMF=20 type-ahead > > It would seem like we're not trying to buffer audio (generally) > but only the DIGIT values themselves. > > It would seem better to just be a header such as: > > DTMF-Buffer: > > instead. > > Jeff > > ----------------------------------------------------------- ------------- > *From:* speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] *On Behalf=20 Of *Shanmugham, > Saravanan > *Sent:* Tuesday, August 23, 2005 4:59 PM > *To:* Reifenrath, Klaus; dburnett@vocalocity.net > *Cc:* speechsc@ietf.org > *Subject:* [Speechsc] RE: Problem with DTMF type-ahead > > > I had typed this response out earlier but wanted to see if there > was any support for this capability. So sending=20 it out now. > > The solution I would suggest is a new header > Type-Ahead: > header that can be sent on the SET-PARAMS,=20 GET-PARAMS and > RECOGNIZE methods. > > default is 0 which is todays no buffering case. If set to some > value, the resource is expected to buffer upto > of audio and use it during the recognize as > a type-ahead buffer. I can see this being a boolean field as well, > but the approach is little more flexible. > > Sarvi > > ----------------------------------------------------------- ------------- > *From:* Reifenrath, Klaus [mailto:Klaus.Reifenrath@Scansoft.com] > *Sent:* Tuesday, August 23, 2005 8:41 AM > *To:* Shanmugham, Saravanan;=20 'dburnett@vocalocity.net' > *Cc:* 'speechsc@ietf.org' > *Subject:* Problem with DTMF type-ahead > > The MRCP and MRCPv2 specifications define=20 how DTMF input > should be handled: DTMF input is collected after the RECOGNIZE > request is received until a term-char or timeout is reached. > Then a result or no-match is returned based on any active DTMF > grammars. The problem is there can be a significant amount of > time between when one result is processed by the application > and the next grammar is activated. During that time any DTMF > input received will be lost. Such DTMF type-ahead is common > for frequent users of IVR systems, and buffering that type > ahead is required by VoiceXML 2.0 (see section 4.1.8). Can > this requirement of VoiceXML be implemented=20 using MRCP > (assuming that the media source CANNOT buffer DTMF)? If so, > how is it done? > > Thanks, > Klaus > >---------------------------------------------------------- ------------- - > >_______________________________________________ >Speechsc mailing list >Speechsc@ietf.org >https://www1.ietf.org/mailman/listinfo/speechsc > > =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Aug 24 15:59:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81P2-0000j5-U6; Wed, 24 Aug 2005 15:59:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81Oz-0000eR-SF for speechsc@megatron.ietf.org; Wed, 24 Aug 2005 15:59:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16467 for ; Wed, 24 Aug 2005 15:59:12 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E81PN-0005cH-17 for speechsc@ietf.org; Wed, 24 Aug 2005 15:59:37 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 24 Aug 2005 12:59:04 -0700 Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7OJwq0T008458; Wed, 24 Aug 2005 12:59:00 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead Date: Wed, 24 Aug 2005 12:56:46 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C2C42C5@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] RE: Problem with DTMF type-ahead Thread-Index: AcWokY2nOWUMZ0/RTlajUyiwMSDepAADFCrAAA5tVzAAAK6aMAACiJ4A From: "Shanmugham, Saravanan" To: "Eric Burger" X-Spam-Score: 0.0 (/) X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6 Content-Transfer-Encoding: quoted-printable Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org I am less concerned about DoS attacks.=20 We are implementing a recognition resource that could potentially be attached a=20 Speaker for the entire period of the call, without actually doing any actual=20 Recognition. Soemtime way into the call the application might play a prompt and start a Recognize. The question is will any digits pressed during the call be applied because the buffer was too long. Note that we are actually saying the resource would be buffering digits even when there is no Recognize happenning. Anyway, If there is much interest in the group for supporting variable buffer size, Iwill not push it. Sarvi -----Original Message----- From: Eric Burger [mailto:eburger@brooktrout.com]=20 Sent: Wednesday, August 24, 2005 11:39 AM To: Shanmugham, Saravanan Cc: speechsc@ietf.org Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead =20 [not as chair] I still see no use case for NOT having the buffer go back=20 to the beginning of time. Since there is no need for a=20 limit to the buffer size, why complicate things? =20 Because someone will always come up with a bizarre corner=20 case, KPML does do a circular buffer thing, dropping real=20 old tones, and indicating that old tones were lost. =20 However, even on a memory constrained telephone, that=20 would be hours of digits being entered continuously (i.e.,=20 still probably never could happen). =20 Thus, to the question of "Should the client set the buffer=20 size?" the answer is "no". The size is effectively=20 infinite. "Is the size set by the platform?" I would say=20 "no", because there is no reason to. However, if you are ultra paranoid about a DoS attack that=20 runs for a really long time (which in itself is going to=20 be the source of the problem, not that your DTMF buffer=20 overflows), I suppose one could say "yes". =20 My personal opinion is still to just have an infinite=20 buffer size, going back to the last recognition / start of=20 buffering / last flush. =20 -----Original Message----- From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] Sent: Wednesday, August 24, 2005 2:22 PM To: Eric Burger; Dave Burke Cc: speechsc@ietf.org Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead =20 Ok. Lets limit this buffer to digits and not speech.=20 Lets also stick to clear buffer operation in RECOGNIZE method. =20 But should be the buffer size. Settable by the client?=20 Platform specific fixed? Settable client on a per RECOGNIZE basis. =20 Unlimited size may be ok for implementation, but is it=20 practical and what does it mean in actual usage.=20 If the recognizer channel was allocated at the beginning=20 of the call, and at some later point in the call, much=20 later, we do a recognize. Does this mean that any digits=20 pressed since the beginning of the call when the resource=20 was allocated or the previous RECOGNIZE, are used as part=20 of the type-ahead? =20 Sarvi=20 =20 -----Original Message----- From: Eric Burger [mailto:eburger@brooktrout.com]=20 Sent: Wednesday, August 24, 2005 4:31 AM To: Dave Burke; Shanmugham, Saravanan Cc: speechsc@ietf.org Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead =20 [not as chair] We went through this whole discussion for KPML. No one=20 ever had a use case for "keep the last x seconds". In=20 fact, one either buffered digits or flushed them. =20 If you have an 8,000 port media engine, with one hour call=20 times, and continuous digit entry without the digits ever=20 getting off the queue, and the digit entry is computer=20 generated (i.e., as fast as possible), you need: (8,000 ports) * (3,600,000ms/port) / (60ms / digit) =3D = 480MB =20 I would offer that if you have an 8,000 port media=20 processing device, less than half a gigabyte for digit=20 buffering is nothing. =20 In English, that means that you can realistically have=20 infinite digit buffering. =20 That makes the protocol MUCH easier, interoperation MUCH=20 easier, and implementation MUCH easier. =20 [really not as chair] As for the term, I didn't think anyone had an alternative=20 interpretation of the term "flush". However, I suppose=20 "clear" is OK. =20 -----Original Message----- From: Dave Burke [mailto:david.burke@voxpilot.com] Sent: Wednesday, August 24, 2005 5:52 AM To: Shanmugham, Saravanan; Eric Burger; speechsc@ietf.org Subject: Re: [Speechsc] RE: Problem with DTMF type-ahead =20 Sounds like a lot of dials to play with: What is the=20 use-case warranting the extra complexity for overriding=20 the SET-PARAMed buffer length on a per RECOGNIZE? =20 The two capabilities that you want (IMO) are: 1. Configuration: How long is the buffer? 2. Action: Flush buffer =20 For configuration, I'd rather see a SET-PARAMs but with a=20 non-zero default - say 10 seconds (2 x default inter-digit=20 time). For flushing, I'd rather see a boolean header on=20 RECOGNIZE for simplicity. That way, out-of-the-box, easy=20 things are easy and harder things are still possible... =20 I don't like the term flush. Is one flushing the DTMF into=20 the recognizer or out into the ether(net)? Hence why I=20 suggested Clear-DTMF-Buffer. =20 Dave =20 ----- Original Message ----- From: "Shanmugham, Saravanan" To: "Eric Burger" ;=20 Sent: Wednesday, August 24, 2005 7:43 AM Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead =20 =20 The idea of being able to send it opn the RECOGNIZE is to=20 reduce the time and not increase it. =20 By default, the value is 0. When you do a SET-PARAMS and=20 set it to say 10000 it sets the buffering at the server to 10 seconds. =20 This does not mean that every RECOGNIZE should use this=20 entire 10s of buffer. On an individual RECOGNIZE method basis the client=20 should be able to use 0 - 10s of that buffer. This would be the last=20 X seconds of the buffer before the RECOGNIZE method is recieved the=20 rest would be discarded. =20 Achieves more flexibility than plain flushing true or false. =20 Sarvi =20 -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of=20 Eric Burger Sent: Tuesday, August 23, 2005 11:14 PM To: speechsc@ietf.org Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead =20 [not as chair] =20 I can see something like "Type-Ahead" for SET/GET-PARAMS, which sets a global digit buffer. I would suggest a more descriptive name, like DTMF-Buffer-Time. =20 That said, I don't see it working for the RECOGNIZE method. The speech resource needs to know *before* the RECOGNIZE request that it needs to buffer DTMF. If it comes in with the RECOGNIZE request, it will be too late. =20 For example: =20 SET-PARAMS DTMF-Buffer-Time: 10000 ... =20 =20 RECOGNIZE DTMF-Buffer-Time: 20000 ... =20 =20 =20 The sensible per-RECOGNIZE attribute is to flush the buffer. While one might be tempted to say "DTMF-Buffer-Time: 0" means flush the buffer, I am sure someone will try to use it with a non-zero=20 value. I would offer we use a different attribute to indicate flushing the buffer before recognition, like "Flush-DTMF: true". =20 -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of=20 Corby Anderson Sent: Tuesday, August 23, 2005 7:34 PM To: speechsc@ietf.org Subject: Re: [Speechsc] RE: Problem with DTMF type-ahead =20 I prefer the flexible "Type-Ahead:=20 " approach. This would be useful for implementing vxml listen states that happen after data tags. If a data fetch=20 takes longer than several seconds, you =20 might not want to play dtmf that is older than=20 some limit. =20 Corby Anderson Tellme Networks, Inc. =20 Shanmugham, Saravanan wrote: =20 > Are we assuming then that this is only limited to DTMF type-ahead and > is not speak ahead as well? > > Sarvi > > =20 ----------------------------------------------------------- ------------- > *From:* Jeff Haynie [mailto:jhaynie@vocalocity.net] > *Sent:* Tuesday, August 23, 2005 3:20 PM > *To:* Shanmugham, Saravanan; Reifenrath, Klaus; > dburnett@vocalocity.net > *Cc:* speechsc@ietf.org > *Subject:* RE: [Speechsc] RE: Problem with DTMF=20 type-ahead > > It would seem like we're not trying to buffer audio (generally) > but only the DIGIT values themselves. > > It would seem better to just be a header such as: > > DTMF-Buffer: > > instead. > > Jeff > > =20 ----------------------------------------------------------- ------------- > *From:* speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] *On Behalf=20 Of *Shanmugham, > Saravanan > *Sent:* Tuesday, August 23, 2005 4:59 PM > *To:* Reifenrath, Klaus; dburnett@vocalocity.net > *Cc:* speechsc@ietf.org > *Subject:* [Speechsc] RE: Problem with=20 DTMF type-ahead > > > I had typed this response out earlier but wanted to see if there > was any support for this capability. So sending=20 it out now. > > The solution I would suggest is a new header > Type-Ahead: > header that can be sent on the SET-PARAMS,=20 GET-PARAMS and > RECOGNIZE methods. > > default is 0 which is todays no buffering case. If set to some > value, the resource is expected to buffer upto > of audio and use it during the recognize as > a type-ahead buffer. I can see this being a boolean field as well, > but the approach is little more flexible. > > Sarvi > > =20 ----------------------------------------------------------- ------------- > *From:* Reifenrath, Klaus [mailto:Klaus.Reifenrath@Scansoft.com] > *Sent:* Tuesday, August 23, 2005 8:41 AM > *To:* Shanmugham, Saravanan;=20 'dburnett@vocalocity.net' > *Cc:* 'speechsc@ietf.org' > *Subject:* Problem with DTMF type-ahead > > The MRCP and MRCPv2 specifications define=20 how DTMF input > should be handled: DTMF input is=20 collected after the RECOGNIZE > request is received until a term-char=20 or timeout is reached. > Then a result or no-match is returned based on any active DTMF > grammars. The problem is there can be a significant amount of > time between when one result is=20 processed by the application > and the next grammar is activated. During that time any DTMF > input received will be lost. Such DTMF type-ahead is common > for frequent users of IVR systems, and=20 buffering that type > ahead is required by VoiceXML 2.0 (see section 4.1.8). Can > this requirement of VoiceXML be implemented=20 using MRCP > (assuming that the media source CANNOT buffer DTMF)? If so, > how is it done? > > Thanks, > Klaus > =20 >---------------------------------------------------------- ------------- - > >_______________________________________________ >Speechsc mailing list >Speechsc@ietf.org >https://www1.ietf.org/mailman/listinfo/speechsc > > =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Aug 24 16:18:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81ht-0000zl-Ff; Wed, 24 Aug 2005 16:18:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81hq-0000zf-Rl for speechsc@megatron.ietf.org; Wed, 24 Aug 2005 16:18:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18286 for ; Wed, 24 Aug 2005 16:18:41 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E81iE-0006dv-8j for speechsc@ietf.org; Wed, 24 Aug 2005 16:19:06 -0400 Received: from ATLANTIS.Brooktrout.com (oceans11.brooktrout.com [204.176.75.121]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j7OK1V0Y012470; Wed, 24 Aug 2005 16:01:31 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead Date: Wed, 24 Aug 2005 16:01:27 -0400 Message-ID: <330A23D8336C0346B5C1A5BB19666647E06B63@ATLANTIS.Brooktrout.com> Thread-Topic: [Speechsc] RE: Problem with DTMF type-ahead Thread-Index: AcWokY2nOWUMZ0/RTlajUyiwMSDepAADFCrAAA5tVzAAAK6aMAACiJ4AAAB/NxA= From: "Eric Burger" To: "Shanmugham, Saravanan" X-Spam-Score: 0.0 (/) X-Scan-Signature: 441f623df000f14368137198649cb083 Content-Transfer-Encoding: quoted-printable Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Having variable or infinite buffering would not change the client behavior in the example given below. At some point, the client says, "I am interested in digits starting NOW." The "NOW" point is where the client flushes the buffer. Anything else would not be deterministic. -----Original Message----- From: Shanmugham, Saravanan [mailto:sarvi@cisco.com]=20 Sent: Wednesday, August 24, 2005 3:57 PM To: Eric Burger Cc: speechsc@ietf.org Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead I am less concerned about DoS attacks.=20 We are implementing a recognition resource that could potentially be attached a=20 Speaker for the entire period of the call, without actually doing any actual=20 Recognition. Soemtime way into the call the application might play a prompt and start a Recognize. The question is will any digits pressed during the call be applied because the buffer was too long. Note that we are actually saying the resource would be buffering digits even when there is no Recognize happenning. Anyway, If there is much interest in the group for supporting variable buffer size, Iwill not push it. Sarvi -----Original Message----- From: Eric Burger [mailto:eburger@brooktrout.com]=20 Sent: Wednesday, August 24, 2005 11:39 AM To: Shanmugham, Saravanan Cc: speechsc@ietf.org Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead =20 [not as chair] I still see no use case for NOT having the buffer go back=20 to the beginning of time. Since there is no need for a=20 limit to the buffer size, why complicate things? =20 Because someone will always come up with a bizarre corner=20 case, KPML does do a circular buffer thing, dropping real=20 old tones, and indicating that old tones were lost. =20 However, even on a memory constrained telephone, that=20 would be hours of digits being entered continuously (i.e.,=20 still probably never could happen). =20 Thus, to the question of "Should the client set the buffer=20 size?" the answer is "no". The size is effectively=20 infinite. "Is the size set by the platform?" I would say=20 "no", because there is no reason to. However, if you are ultra paranoid about a DoS attack that=20 runs for a really long time (which in itself is going to=20 be the source of the problem, not that your DTMF buffer=20 overflows), I suppose one could say "yes". =20 My personal opinion is still to just have an infinite=20 buffer size, going back to the last recognition / start of=20 buffering / last flush. =20 -----Original Message----- From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] Sent: Wednesday, August 24, 2005 2:22 PM To: Eric Burger; Dave Burke Cc: speechsc@ietf.org Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead =20 Ok. Lets limit this buffer to digits and not speech.=20 Lets also stick to clear buffer operation in RECOGNIZE method. =20 But should be the buffer size. Settable by the client?=20 Platform specific fixed? Settable client on a per RECOGNIZE basis. =20 Unlimited size may be ok for implementation, but is it=20 practical and what does it mean in actual usage.=20 If the recognizer channel was allocated at the beginning=20 of the call, and at some later point in the call, much=20 later, we do a recognize. Does this mean that any digits=20 pressed since the beginning of the call when the resource=20 was allocated or the previous RECOGNIZE, are used as part=20 of the type-ahead? =20 Sarvi=20 =20 -----Original Message----- From: Eric Burger [mailto:eburger@brooktrout.com]=20 Sent: Wednesday, August 24, 2005 4:31 AM To: Dave Burke; Shanmugham, Saravanan Cc: speechsc@ietf.org Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead =20 [not as chair] We went through this whole discussion for KPML. No one=20 ever had a use case for "keep the last x seconds". In=20 fact, one either buffered digits or flushed them. =20 If you have an 8,000 port media engine, with one hour call=20 times, and continuous digit entry without the digits ever=20 getting off the queue, and the digit entry is computer=20 generated (i.e., as fast as possible), you need: (8,000 ports) * (3,600,000ms/port) / (60ms / digit) =3D = 480MB =20 I would offer that if you have an 8,000 port media=20 processing device, less than half a gigabyte for digit=20 buffering is nothing. =20 In English, that means that you can realistically have=20 infinite digit buffering. =20 That makes the protocol MUCH easier, interoperation MUCH=20 easier, and implementation MUCH easier. =20 [really not as chair] As for the term, I didn't think anyone had an alternative=20 interpretation of the term "flush". However, I suppose=20 "clear" is OK. =20 -----Original Message----- From: Dave Burke [mailto:david.burke@voxpilot.com] Sent: Wednesday, August 24, 2005 5:52 AM To: Shanmugham, Saravanan; Eric Burger; speechsc@ietf.org Subject: Re: [Speechsc] RE: Problem with DTMF type-ahead =20 Sounds like a lot of dials to play with: What is the=20 use-case warranting the extra complexity for overriding=20 the SET-PARAMed buffer length on a per RECOGNIZE? =20 The two capabilities that you want (IMO) are: 1. Configuration: How long is the buffer? 2. Action: Flush buffer =20 For configuration, I'd rather see a SET-PARAMs but with a=20 non-zero default - say 10 seconds (2 x default inter-digit=20 time). For flushing, I'd rather see a boolean header on=20 RECOGNIZE for simplicity. That way, out-of-the-box, easy=20 things are easy and harder things are still possible... =20 I don't like the term flush. Is one flushing the DTMF into=20 the recognizer or out into the ether(net)? Hence why I=20 suggested Clear-DTMF-Buffer. =20 Dave =20 ----- Original Message ----- From: "Shanmugham, Saravanan" To: "Eric Burger" ;=20 Sent: Wednesday, August 24, 2005 7:43 AM Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead =20 =20 The idea of being able to send it opn the RECOGNIZE is to=20 reduce the time and not increase it. =20 By default, the value is 0. When you do a SET-PARAMS and=20 set it to say 10000 it sets the buffering at the server to 10 seconds. =20 This does not mean that every RECOGNIZE should use this=20 entire 10s of buffer. On an individual RECOGNIZE method basis the client=20 should be able to use 0 - 10s of that buffer. This would be the last=20 X seconds of the buffer before the RECOGNIZE method is recieved the=20 rest would be discarded. =20 Achieves more flexibility than plain flushing true or false. =20 Sarvi =20 -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of=20 Eric Burger Sent: Tuesday, August 23, 2005 11:14 PM To: speechsc@ietf.org Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead =20 [not as chair] =20 I can see something like "Type-Ahead" for SET/GET-PARAMS, which sets a global digit buffer. I would suggest a more descriptive name, like DTMF-Buffer-Time. =20 That said, I don't see it working for the RECOGNIZE method. The speech resource needs to know *before* the RECOGNIZE request that it needs to buffer DTMF. If it comes in with the RECOGNIZE request, it will be too late. =20 For example: =20 SET-PARAMS DTMF-Buffer-Time: 10000 ... =20 =20 RECOGNIZE DTMF-Buffer-Time: 20000 ... =20 =20 =20 The sensible per-RECOGNIZE attribute is to flush the buffer. While one might be tempted to say "DTMF-Buffer-Time: 0" means flush the buffer, I am sure someone will try to use it with a non-zero=20 value. I would offer we use a different attribute to indicate flushing the buffer before recognition, like "Flush-DTMF: true". =20 -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of=20 Corby Anderson Sent: Tuesday, August 23, 2005 7:34 PM To: speechsc@ietf.org Subject: Re: [Speechsc] RE: Problem with DTMF type-ahead =20 I prefer the flexible "Type-Ahead:=20 " approach. This would be useful for implementing vxml listen states that happen after data tags. If a data fetch=20 takes longer than several seconds, you =20 might not want to play dtmf that is older than=20 some limit. =20 Corby Anderson Tellme Networks, Inc. =20 Shanmugham, Saravanan wrote: =20 > Are we assuming then that this is only limited to DTMF type-ahead and > is not speak ahead as well? > > Sarvi > > =20 ----------------------------------------------------------- ------------- > *From:* Jeff Haynie [mailto:jhaynie@vocalocity.net] > *Sent:* Tuesday, August 23, 2005 3:20 PM > *To:* Shanmugham, Saravanan; Reifenrath, Klaus; > dburnett@vocalocity.net > *Cc:* speechsc@ietf.org > *Subject:* RE: [Speechsc] RE: Problem with DTMF=20 type-ahead > > It would seem like we're not trying to buffer audio (generally) > but only the DIGIT values themselves. > > It would seem better to just be a header such as: > > DTMF-Buffer: > > instead. > > Jeff > > =20 ----------------------------------------------------------- ------------- > *From:* speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] *On Behalf=20 Of *Shanmugham, > Saravanan > *Sent:* Tuesday, August 23, 2005 4:59 PM > *To:* Reifenrath, Klaus; dburnett@vocalocity.net > *Cc:* speechsc@ietf.org > *Subject:* [Speechsc] RE: Problem with=20 DTMF type-ahead > > > I had typed this response out earlier but wanted to see if there > was any support for this capability. So sending=20 it out now. > > The solution I would suggest is a new header > Type-Ahead: > header that can be sent on the SET-PARAMS,=20 GET-PARAMS and > RECOGNIZE methods. > > default is 0 which is todays no buffering case. If set to some > value, the resource is expected to buffer upto > of audio and use it during the recognize as > a type-ahead buffer. I can see this being a boolean field as well, > but the approach is little more flexible. > > Sarvi > > =20 ----------------------------------------------------------- ------------- > *From:* Reifenrath, Klaus [mailto:Klaus.Reifenrath@Scansoft.com] > *Sent:* Tuesday, August 23, 2005 8:41 AM > *To:* Shanmugham, Saravanan;=20 'dburnett@vocalocity.net' > *Cc:* 'speechsc@ietf.org' > *Subject:* Problem with DTMF type-ahead > > The MRCP and MRCPv2 specifications define=20 how DTMF input > should be handled: DTMF input is=20 collected after the RECOGNIZE > request is received until a term-char=20 or timeout is reached. > Then a result or no-match is returned based on any active DTMF > grammars. The problem is there can be a significant amount of > time between when one result is=20 processed by the application > and the next grammar is activated. During that time any DTMF > input received will be lost. Such DTMF type-ahead is common > for frequent users of IVR systems, and=20 buffering that type > ahead is required by VoiceXML 2.0 (see section 4.1.8). Can > this requirement of VoiceXML be implemented=20 using MRCP > (assuming that the media source CANNOT buffer DTMF)? If so, > how is it done? > > Thanks, > Klaus > =20 >---------------------------------------------------------- ------------- - > >_______________________________________________ >Speechsc mailing list >Speechsc@ietf.org >https://www1.ietf.org/mailman/listinfo/speechsc > > =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Mon Aug 29 10:34:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9kiV-0006Sq-1l; Mon, 29 Aug 2005 10:34:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9kiT-0006Sl-9q for speechsc@megatron.ietf.org; Mon, 29 Aug 2005 10:34:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13587 for ; Mon, 29 Aug 2005 10:34:27 -0400 (EDT) Received: from tidos.tid.es ([193.145.240.2] helo=correo.tid.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9kjm-0001dz-DG for speechsc@ietf.org; Mon, 29 Aug 2005 10:35:53 -0400 Received: from tid (filvit [192.168.48.202]) by tid.hi.inet (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0ILZ000LYN6EQ7@tid.hi.inet> for speechsc@ietf.org; Mon, 29 Aug 2005 16:35:02 +0200 (MEST) Received: from tid.es (valldigna.hi.inet [10.95.12.129]) by tid.hi.inet (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0ILZ000LCN6DQ7@tid.hi.inet> for speechsc@ietf.org; Mon, 29 Aug 2005 16:35:01 +0200 (MEST) Date: Mon, 29 Aug 2005 16:34:04 +0200 From: =?ISO-8859-1?Q?Jes=FAs_Bernat_Vercher?= To: speechsc@ietf.org Message-id: <43131CDC.1030304@tid.es> Organization: =?iso-8859-1?Q?Telef=F3nica_I=2BD?= MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: es-es, es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.6) Gecko/20040113 X-imss-version: 2.7 X-imss-result: Passed X-imss-scores: Clean:87.33951 C:22 M:1 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7BIT Subject: [Speechsc] Question about Contiguous Request-ID's X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org We already had a discussion on this issue (http://www1.ietf.org/mail-archive/web/speechsc/current/msg01260.html) It ended saying to change the draft to define the request-id as monotonically increasing and to define some errors: "So, the above is the long way of saying I think we should do (2), and reject duplicate and out-of-order requests with a well-defined error. " Is there any specific error in the currect draft for duplicated or out-of-order request-id's? Thanks: Jesus. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc