From speechsc-bounces@ietf.org Mon Nov 3 11:30:04 2008 Return-Path: X-Original-To: speechsc-archive@optimus.ietf.org Delivered-To: ietfarch-speechsc-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6961E28C21C; Mon, 3 Nov 2008 11:30:04 -0800 (PST) X-Original-To: speechsc@ietf.org Delivered-To: speechsc@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5CD393A67F3; Mon, 3 Nov 2008 11:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081103193001.5CD393A67F3@core3.amsl.com> Date: Mon, 3 Nov 2008 11:30:01 -0800 (PST) Cc: speechsc@ietf.org Subject: [Speechsc] I-D Action:draft-ietf-speechsc-mrcpv2-17.txt X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: 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) : S. Shanmugham, D. Burnett Filename : draft-ietf-speechsc-mrcpv2-17.txt Pages : 215 Date : 2008-11-03 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-17.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-speechsc-mrcpv2-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-03112049.I-D@ietf.org> --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://www.ietf.org/mailman/listinfo/speechsc Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> --NextPart-- From speechsc-bounces@ietf.org Mon Nov 3 11:42:26 2008 Return-Path: X-Original-To: speechsc-archive@optimus.ietf.org Delivered-To: ietfarch-speechsc-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 512E13A6B0B; Mon, 3 Nov 2008 11:42:26 -0800 (PST) X-Original-To: speechsc@core3.amsl.com Delivered-To: speechsc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 087083A691B for ; Mon, 3 Nov 2008 11:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usDiLSPsvn8Q for ; Mon, 3 Nov 2008 11:42:24 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with SMTP id 7286B3A6BC0 for ; Mon, 3 Nov 2008 11:42:15 -0800 (PST) Received: from [76.111.40.166] (account dburnett HELO [192.168.15.123]) by voxeo.com (CommuniGate Pro SMTP 5.2.3) with ESMTPSA id 36597527 for speechsc@ietf.org; Mon, 03 Nov 2008 19:42:13 +0000 Message-Id: From: Dan Burnett To: speechsc@ietf.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 3 Nov 2008 14:42:10 -0500 X-Mailer: Apple Mail (2.929.2) Subject: [Speechsc] Changes from draft -16 to draft -17 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Group, No, this still does not address all of the review comments, but I wanted to get a version out before today's publication cutoff. Here are the changes in this draft. -- dan - Clarified in 8.13 that the SPEECH-MARKER event MUST be generated when a SPEAK request in Pending-State changes state to IN-PROGRESS. - Modified ABNF for request-id to be 1*10DIGIT to align with text, which restricts values to 32 bits. - Clarified that the Accept header can only occur in requests (in addition to SET-PARAMS and GET-PARAMS) - Clarified that the Proxy-sync-id header MAY occur only on events and the BARGE-IN-OCCURRED method. - Clarified that the Accept-charset and Cache-control headers are only used on requests. - Clarified that the Content-type, Content-ID, Content-Base, Content- Encoding, Content-Location, and Content-Length may be used on all messages. - Clarified that the Save-Waveform and Recognition-mode headers can only occur on RECOGNIZE, SET-PARAMS, or GET-PARAMS. - Clarified that the Personal-Grammar-URI and Save-Best-Waveform headers can only be sent as part of the START-PHRASE-ENROLLMENT, SET- PARAMS, GET-PARAMS methods. - Clarified that if a media processing resource is requested to be added to an existing session and the resource is not available, the media processing going on before the RE-INVITE will continue as it was before. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www.ietf.org/mailman/listinfo/speechsc Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> From speechsc-bounces@ietf.org Thu Nov 20 16:49:47 2008 Return-Path: X-Original-To: speechsc-archive@optimus.ietf.org Delivered-To: ietfarch-speechsc-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0127728C16C; Thu, 20 Nov 2008 16:49:47 -0800 (PST) X-Original-To: speechsc@core3.amsl.com Delivered-To: speechsc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45EBA3A68B4 for ; Thu, 20 Nov 2008 16:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.489 X-Spam-Level: X-Spam-Status: No, score=-0.489 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599, RELAY_IS_203=0.994, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rK49OGh3vJ2l for ; Thu, 20 Nov 2008 16:47:44 -0800 (PST) Received: from mail02.kaz-group.com (mail02.kaz-group.com [203.28.13.56]) by core3.amsl.com (Postfix) with ESMTP id 1D1313A6873 for ; Thu, 20 Nov 2008 16:47:43 -0800 (PST) Received: from AUKGHB01.Corporate.KAZ-Group.priv (aukghb01.corporate.kaz-group.priv) by mail02.kaz-group.com (Clearswift SMTPRS 5.2.5) with ESMTP id for ; Fri, 21 Nov 2008 11:47:33 +1100 Date: Fri, 21 Nov 2008 11:47:35 +1100 MIME-Version: 1.0 To: speechsc@ietf.org Cc: From: Nik Waldron X-Mailer: Microsoft Outlook v 11.00.8217, MSOC v 2.00.4007.00 Message-ID: X-MIMETrack: Serialize by Router on AUKGHB01/KAZGROUP/AU(Release 6.5.2|June 01, 2004) at 11/21/2008 11:47:39 AM, Serialize complete at 11/21/2008 11:47:39 AM X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: [Speechsc] FW: MRCPV2 Verification: Insufficient/bad speech X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org A resubmit of the previous question accidentally sent as Rich Text _____________________________________________ From: Nik Waldron Sent: Friday, November 21, 2008 9:52 AM To: 'speechsc@ietf.org' Subject: MRCPV2 Verification: Insufficient/bad speech My question regards the training phase in a speaker verification session: My reading of the draft RFC is that a training session may be initiated by a VERIFY call, and that the speech data streamed via RTP is then used to build the model. Implicit in the design is that when a speaker is deemed to have finished a turn in the dialog (say answering a voice enrolment question), the verification system will return a VERIFICATION-COMPLETE. I am currently assuming that this is a detected "end-of-speech" condition. Further VERIFY calls may then be used to refine the speaker model. My confusion arises when speech has been detected, but the speech is for some reason unsuitable to complete training with (e.g. there is not enough speech, the speech is too noisy etc.). How should the verifier respond? In the use case I am working on the desired behaviour is for the client to VERIFY again on the same session and pass through more speech data, but I can't seem to find a suitable error code/completion cause (the generic "error" completion code seems to suit a serious internal error only). I was expecting an "insufficient data" and/or "bad quality data" type feedback to the client. Alternatively is the timing of the VERIFY-COMPLETE message not tied to dialogue turns? I have to now assumed that MRCPv2 client (e.g. a VXML browser) did not have its own mechanism for detecting the end of a dialogue turn, hence it needed notification in this case. Can someone let me know which interpretation is correct, or what the correct behaviour of a MRCPv2 server should be? Regards, NIK WALDRON _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www.ietf.org/mailman/listinfo/speechsc Supplemental web site: <http://www.standardstrack.com/ietf/speechsc>