Return-Path: 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 4BE263A6D96 for ; Mon, 11 May 2009 08:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.017 X-Spam-Level: X-Spam-Status: No, score=0.017 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_SORBS_WEB=0.619] 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 zTTNRgyUuvPV for ; Mon, 11 May 2009 08:13:14 -0700 (PDT) Received: from n64.bullet.mail.sp1.yahoo.com (n64.bullet.mail.sp1.yahoo.com [98.136.44.189]) by core3.amsl.com (Postfix) with SMTP id 10F113A684C for ; Mon, 11 May 2009 08:13:14 -0700 (PDT) Received: from [216.252.122.219] by n64.bullet.mail.sp1.yahoo.com with NNFMP; 11 May 2009 15:14:43 -0000 Received: from [67.195.9.83] by t4.bullet.sp1.yahoo.com with NNFMP; 11 May 2009 15:14:43 -0000 Received: from [67.195.9.106] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 11 May 2009 15:14:43 -0000 Received: from [127.0.0.1] by omp110.mail.gq1.yahoo.com with NNFMP; 11 May 2009 15:13:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 420735.27283.bm@omp110.mail.gq1.yahoo.com Received: (qmail 5453 invoked by uid 60001); 11 May 2009 15:14:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1242054883; bh=oFaaHRvIJnjkM009QK7Up1XHKvrXkCLRn3kvAyggRLY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=A6V/22Xr/l+U5SbjLugJiI3/zROJ0ekgcd1y4ClxnxxAOr6fN14PaSo7g3dDQY5L73zPW1pFnO8GFHeGfy+Uhx7scStvfn23cNVDGc13hxlT0uVc62X4aJFjMvSdwizOSbaFQidRY5YIBixBZ+zXWD8BPeqtKZnMt9EoqOrb5aM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=SK7g3pk8+thF2ounC27tYxN5njYuzq8FOXQfceujlFcV3iXIOfIpvApWRYtd2jrIdMeEoFYbKflD9l+tp2vZixEG7S5tGPiTAoZe20HWhpuICMPT0hvL+47UbOjN2FTyJ69/Rb++N9npLKHVQ9D+brFHI4D2rMN9QLEwFiBjW4Y=; Message-ID: <36904.3443.qm@web111304.mail.gq1.yahoo.com> X-YMail-OSG: U3a5U3sVM1lYCNJObq8vc29tKcW7CZ8s5Fo2YdZc.NrEzf9.O8c9NHdZJbhC4j77gtj6hhx268MPwfOl.7ypefNnyPMFjkd.1y_jN6QEfJeU7og7ANzSURN82rjFQjAXb.kN7RKlgEOemRaYnAq44fLAkKg3rEW6q.j5UjtHXnnuzSzuc6hLAH86UUuJ8uHLrURQKoQ.SoWzCbCqOwIbbdTefHKSbH_phBAmVYQkpH.v2hML93eWp6BlKDOPdvRJwW6IliGf9MCUUFV5NfLSgzAba9dy3xnA0Tiqv6fdBZKlQsaqVEG3Cl8QGghFCEegREPT.whwewDQ9oeMfPSwYJjXVRk- Received: from [87.241.181.173] by web111304.mail.gq1.yahoo.com via HTTP; Mon, 11 May 2009 08:14:42 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 References: <6F3109CD-FF17-43A2-A4BE-71A6A488D22D@standardstrack.com> Date: Mon, 11 May 2009 08:14:42 -0700 (PDT) From: Arsen Chaloyan To: Eric Burger , Nik Waldron In-Reply-To: <6F3109CD-FF17-43A2-A4BE-71A6A488D22D@standardstrack.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-69743759-1242054882=:3443" Cc: speechsc@ietf.org Subject: Re: [Speechsc] Speaker Verification - Insufficient or Noisy 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: , X-List-Received-Date: Mon, 11 May 2009 15:13:16 -0000 --0-69743759-1242054882=:3443 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Book is definitely good.=0AHowever SDP o/a examples (RFC4317) like online = resource would be indeed helpful.=0AIt's not matter of just examples, but i= t may also cover error cases.=0AReading the latest draft, it's still not al= ways obvious what error response should be sent in some particular cases. C= learly it's not possible to cover all the cases in foundation specification= ..=0AI'll be happy to create such resource in the scope (web) of open source= MRCP project I maintain, if it makes sense.=0A=0ARegards,=0AArsen Chaloyan= =0Awww.unimrcp.org=0A=0A=0A=0A=0A________________________________=0AFrom: E= ric Burger =0ATo: Nik Waldron =0ACc: speechsc@ietf.org=0ASent: Monday, May 11, 2009 6:59:47 PM= =0ASubject: Re: [Speechsc] Speaker Verification - Insufficient or Noisy Spe= ech=0A=0AI would offer we save it for the book.=0A=0AOn May 10, 2009, at 10= :03 PM, Nik Waldron wrote:=0A=0A> Thanks for your response Dan,=0A> =0A> = =0A> =0A> The additional code resolves the problem (2) of noisy or otherwis= e =E2=80=98bad=E2=80=99 input, and (3) clarifies how to specify that additi= onal data is needed for training.=0A> =0A> =0A> =0A> I had not realised tha= t result structure was intended be used in the case of enrolments as well a= s verifications. I=E2=80=99m not sure if my confusion has reach beyond mys= elf and justifies an explanatory note in the verification section. Thanks = for the clarification in any case.=0A> =0A> =0A> =0A> I think that the docu= ment would benefit from an appendix (or a separate document as is the case = for SDP) which has examples of all of the major use cases. In my opinion e= xamples often resolve confusion for readers learning a new protocol. I not= e that there are examples in the document, although not any training (enrol= ment) examples that I recall for speaker verification.=0A> =0A> =0A> =0A> I= appreciate the enormous effort that goes into producing a standard protoco= l (everyone=E2=80=99s a critic). I=E2=80=99d be happy to contribute some e= xample conversations for Verification if such a section or document eventua= tes.=0A> =0A> =0A> =0A> Best regards,=0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A= > NIK WALDRON=0A> =0A> =0A> =0A> From: dburnett@voxeo.com [mailto:dburnett@= voxeo.com]=0A> Sent: Wednesday, May 06, 2009 6:29 AM=0A> To: Nik Waldron=0A= > Cc: speechsc@ietf.org=0A> Subject: Re: [Speechsc] Speaker Verification - = Insufficient or Noisy Speech=0A> =0A> =0A> =0A> Nik,=0A> =0A> Thanks for yo= ur email.=0A> =0A> There are three cases in what you have described:=0A> = =0A> 1. speech not detected (because of SNR problem, etc.). This will=0A> = return no-input-timeout, just as it would for a speech recognizer.=0A> =0A>= 2. speech detected, neither too early (speech-too-early) nor too much=0A> = (too-much-speech-timeout), but still unusable by the training or=0A> verifi= cation process. Note that this could happen if the speech=0A> passes the e= ndpointer threshold but is too garbled or noisy to be of=0A> use to the ver= ification engine.=0A> This case is not handled in MRCP today. I have added= error code 011,=0A> "speech-not-usable", for this case.=0A> =0A> 3. additi= onal turns are needed: the result element can be=0A> used for t= his. "undecided" was the value we chose to represent the=0A> case where th= e engine did not yet have enough data to decide on a=0A> verification or tr= aining result. Note that training decisions can=0A> also be "accepted" or = "rejected" just like verification results -- the=0A> former case means ther= e is sufficient training data and the new=0A> voiceprint is acceptable. Th= e latter means there is sufficient=0A> training data but the new voiceprint= is rejected, because for example=0A> it is too close to an existing voicep= rint.=0A> =0A> -- dan=0A> =0A> On Jan 11, 2009, at 7:06 PM, Nik Waldron wro= te:=0A> =0A> > I sent an email previously requesting information on how a s= peaker=0A> > verification=0A> > system implementing MRCPv2 should cope in t= he situation, where there=0A> > was=0A> > insufficient or poor quality spee= ch arriving on the RTP audio=0A> > stream. It=0A> > seemed=0A> > to me tha= t was an area of some deficiency in the specification. I=0A> > received no= =0A> > feedback other than one response saying that to his knowledge there= =0A> > were=0A> > no=0A> > other implementers for Speaker Verification.=0A>= >=0A> > Below I outline the MRCPv2 exchanges for a training operation:=0A>= >=0A> > C->S: MRCP/2.0 207 START-SESSION 314161=0A> > Channel-= Identifier:32AECB23433801@speakverify=0A> > Repository-URI:http://= www.example.com/voiceprintdbase/=0A> > Voiceprint-Mode:train=0A> >= Voiceprint-Identifier:johnsmith.voiceprint=0A> >=0A> > S->C: M= RCP/2.0 82 314161 200 COMPLETE=0A> > Channel-Identifier:32AECB2343= 3801@speakverify=0A> >=0A> > C->S: MRCP/2.0 76 VERIFY 314162=0A> > = Channel-Identifier:32AECB23433801@speakverify=0A> >=0A> > S->C: MRCP= /2.0 85 314162 200 IN-PROGRESS=0A> > Channel-Identifier:32AECB2343= 3801@speakverify=0A> >=0A> > The end-point detector show insufficient data = (which is buffered),=0A> > or bad=0A> > signal quality (bad SNR for example= ). Note that no START-OF-INPUT=0A> > has NOT=0A> >=0A> > been sent althoug= h speech has begun.=0A> >=0A> > S->C: MRCP/2.0 140 VERIFICATION-COMPLETE= 314162 COMPLETE=0A> > Channel-Identifier:32AECB23433801@speakveri= fy=0A> > Completion-Cause:002 no-input-timeout=0A> >=0A> > This is= undesirable from my perspective since it gives the=0A> > impression to=0A>= > the=0A> > client that no data has been received (untrue in the insuffici= ent data=0A> > case), and=0A> > provides no distinction between this and th= e "bad data" case. This=0A> > information=0A> > might be of utility to a c= all-flow designer in an IVR system.=0A> >=0A> > I also note that in the cas= e of text-independent verifiers several=0A> > turns=0A> > worth of=0A> > da= ta may be required for a verification. Several rounds of "no input"=0A> > = timeouts=0A> > would surely be confusing to the client, yet this class of v= erifiers=0A> > may=0A> > be unable=0A> > to generate and nlsml+xml response= on the nth dialog turn.=0A> >=0A> > The enrolment might then continue:=0A>= >=0A> > C->S: MRCP/2.0 76 VERIFY 314163=0A> > Channel-Identifi= er:32AECB23433801@speakverify=0A> >=0A> > S->C: MRCP/2.0 85 314163 200 I= N-PROGRESS=0A> > Channel-Identifier:32AECB23433801@speakverify=0A>= >=0A> > S->C: MRCP/2.0 96 START-OF-INPUT 314163 IN-PROGRESS=0A> > = Channel-Identifier:32AECB23433801@speakverify=0A> >=0A> > S->C: MRCP= /2.0 131 VERIFICATION-COMPLETE 314163 COMPLETE=0A> > Channel-Ident= ifier:32AECB23433801@speakverify=0A> > Completion-Cause:000 succes= s=0A> >=0A> > C->S: MRCP/2.0 76 VERIFY 314164=0A> > Channel-Ide= ntifier:32AECB23433801@speakverify=0A> >=0A> > S->C: MRCP/2.0 85 314164 = 200 IN-PROGRESS=0A> > Channel-Identifier:32AECB23433801@speakverif= y=0A> >=0A> > S->C: MRCP/2.0 96 START-OF-INPUT 314164 IN-PROGRESS=0A> > = Channel-Identifier:32AECB23433801@speakverify=0A> >=0A> > S->C: = MRCP/2.0 131 VERIFICATION-COMPLETE 314164 COMPLETE=0A> > Channel-= Identifier:32AECB23433801@speakverify=0A> > Completion-Cause:000 s= uccess=0A> >=0A> > C->S: MRCP/2.0 81 END-SESSION 314174=0A> > C= hannel-Identifier:32AECB23433801@speakverify=0A> >=0A> > S->C: MRCP/2.0 = 82 314174 200 COMPLETE=0A> > Channel-Identifier:32AECB23433801@spe= akverify=0A> >=0A> > Since I received no responses (perhaps due to being cl= ose to the=0A> > holiday=0A> > season),=0A> > I will venture a proposal for= extending the RFC to include the bad=0A> > signal=0A> > cases=0A> > (+ ind= icates an addition, * a modification)=0A> >=0A> > +------------+---------= -----------------=0A> > +---------------------------+=0A> > | Cause-Code = | Cause-Name |=0A> > Description |=0A> > +---= ---------+--------------------------=0A> > +---------------------------+=0A= > > | 000 | success | VERIFY=0A> > or = |=0A> > | | | VERIFY-FROM-=0A> >= BUFFER |=0A> > | | | request= =0A> > completed |=0A> > | | = | successfully. The=0A> > verify |=0A> > | | = | decision can=0A> > be |=0A> > | | = | "accepted",=0A> > "rejected", |=0A> > | = | | or=0A> > "undecided". |=0A> > | 00= 1 | error | VERIFY=0A> > or |=0A>= > | | | VERIFY-FROM-=0A> > BUFFER = |=0A> > | | | request=0A> > term= inated |=0A> > | | | premature= ly due to=0A> > a |=0A> > | | | = verification resource=0A> > or |=0A> > | | = | system=0A> > error. |=0A> > | 002 | no-input-= timeout | VERIFY request=0A> > completed |=0A> > | | = | with no result due to=0A> > a |=0A> > | = | | no-input-=0A> > timeout. |=0A> = > | 003 | too-much-speech-timeout | VERIFY request=0A> > complete= d |=0A> > | | | result due to too=0A= > > much |=0A> > | | |=0A> > speec= h. |=0A> > | 004 | speech-too-early | VE= RIFY request=0A> > completed |=0A> > | | = | with no result due=0A> > to |=0A> > | | = | spoke too=0A> > soon. |=0A> > + | 005 | in= sufficient-speech | VERIFY=0A> > or |=0A> > + | = | | VERIFY-FROM-=0A> > BUFFER |=0A> > = + | | | request=0A> > completed = |=0A> > + | | | successfully but=0A> >= had |=0A> > + | | | insufficient = speech=0A> > to |=0A> > + | | | comp= lete. More=0A> > speech |=0A> > + | | = | will complete the=0A> > current |=0A> > + | | = | incremental=0A> > operation |=0A> > + | 006 | bad-= speech | VERIFY=0A> > or |=0A> > + | = | | VERIFY-FROM-=0A> > BUFFER |=0A> > + = | | | request=0A> > completed |= =0A> > + | | | unsuccessfully,=0A> > th= e |=0A> > + | | | speech quality = was=0A> > too |=0A> > + | | |=0A> > = poor |=0A> > * | 007 | buffer-empty = | VERIFY-FROM-=0A> > BUFFER |=0A> > | | = | request completed with=0A> > no |=0A> > | | = | result due to=0A> > empty |=0A> > | = | |=0A> > buffer. |=0A> > * = | 008 | out-of-sequence | Verification=0A> > operation |= =0A> > | | | failed due=0A> > to = |=0A> > | | | out-of-sequence= =0A> > method |=0A> > | | | invoca= tions. For=0A> > example |=0A> > | | = | calling VERIFY=0A> > before |=0A> > | | = | QUERY-=0A> > VOICEPRINT. |=0A> > * | 009 | repo= sitory-uri-failure | Failure=0A> > accessing |=0A> > | = | | Repository=0A> > URI. |=0A> > * = | 010 | repository-uri-missing | Repository-uri is=0A> > not |= =0A> > | | |=0A> > specified. = |=0A> > * | 011 | voiceprint-id-missing | Voiceprint-=0A= > > identification |=0A> > | | | is n= ot=0A> > specified. |=0A> > * | 012 | voiceprint-id-not-exi= st | Voiceprint-=0A> > identification |=0A> > | | = | does not exist in=0A> > the |=0A> > | | = | voiceprint=0A> > repository. |=0A> > +-------= -----+--------------------------=0A> > +---------------------------+=0A> >= =0A> > Alternatively the new entries could be appended for compatibility.= =0A> > The=0A> > only=0A> > disadvantage to doing so would be that entries = would not be grouped=0A> > in the=0A> > table by category.=0A> >=0A> > I'll= happily accept any corrections to my understanding, incase I have=0A> > mi= sread=0A> > the spec, or feedback on my suggestions.=0A> >=0A> >=0A> >=0A> = >=0A> > NIK WALDRON=0A> >=0A> > ___________________________________________= ____=0A> > Speechsc mailing list=0A> > Speechsc@ietf.org=0A> > https://www.= ietf.org/mailman/listinfo/speechsc=0A> > Supplemental web site:=0A> > =0A> =0A> =0A> ____________________= __________________________________________________=0A> This email has been = scanned by the MessageLabs Email Security System.=0A> For more information = please visit http://www.messagelabs.com/email=0A> _________________________= _____________________________________________=0A> =0A> =0A> This is an emai= l from Fujitsu Australia Limited, ABN 19 001 011 427. It is confidential to= the ordinary user of the email address to which it was addressed and may c= ontain copyright and/or legally privileged information. No one else may rea= d, print, store, copy or forward all or any of it or its attachments. If yo= u receive this email in error, please return to sender. Thank you.=0A> ____= __________________________________________________________________=0A> This= email has been scanned by the MessageLabs Email Security System.=0A> For m= ore information please visit http://www.messagelabs.com/email=0A> _________= _____________________________________________________________=0A> _________= ______________________________________=0A> Speechsc mailing list=0A> Speech= sc@ietf.org=0A> https://www.ietf.org/mailman/listinfo/speechsc=0A> Suppleme= ntal web site:=0A> --0-69743759-1242054882=:3443 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Book is definitely good.
However  SDP o/a examples (RFC4317= ) like online resource would be indeed helpful.
It's not matter of just = examples, but it may also cover error cases.
Reading the latest draft, i= t's still not always obvious what error response should be sent in some par= ticular cases. Clearly it's not possible to cover all the cases in foundati= on specification.
I'll be happy to create such resource in the scope (we= b) of open source MRCP project I maintain, if it makes sense.

Regard= s,
Arsen Chaloyan
www.unimrcp.org

From: Eric Bur= ger <eburger@standardstrack.com>
To: Nik Waldron <nik.waldron@kaz-group.com>
Cc: speechsc@ietf.org
Sent: Monday, May 11, 2009 6:59:4= 7 PM
Subject: Re: [Spee= chsc] Speaker Verification - Insufficient or Noisy Speech

=0A= I would offer we save it for the book.

On May 10, 2009, at 10:03 PM,= Nik Waldron wrote:

> Thanks for your response Dan,
>
&= gt;
>
> The additional code resolves the problem (2) of noisy= or otherwise =E2=80=98bad=E2=80=99 input, and (3) clarifies how to specify= that additional data is needed for training.
>
>
> > I had not realised that result structure was intended be used in the = case of enrolments as well as verifications.  I=E2=80=99m not sure if = my confusion has reach beyond myself and justifies an explanatory note in t= he verification section.  Thanks for the clarification in any case.>
>
>
> I think that the document would benefit fr= om an appendix (or a separate document as is the case for SDP) which has ex= amples of all of the major use cases.  In my opinion examples often re= solve confusion for readers learning a new protocol.  I note that ther= e are examples in the document, although not any training (enrolment) examples t= hat I recall for speaker verification.
>
>
>
> I= appreciate the enormous effort that goes into producing a standard protoco= l (everyone=E2=80=99s a critic).  I=E2=80=99d be happy to contribute s= ome example conversations for Verification if such a section or document ev= entuates.
>
>
>
> Best regards,
>
>=
>
>
>
>
>
> NIK WALDRON
> =
>
>
> From: dburnett@voxeo.com [mailto:dburnett@= voxeo.com]
> Sent: Wednesday, May 06, 2009 6:29 AM
> To: Ni= k Waldron
> Cc: speechsc@ietf.org
> Subject: Re: [Speechsc] = Speaker Verification - Insufficient or Noisy Speech
>
>
>
= > Nik,
>
> Thanks for your email.
>
> There ar= e three cases in what you have described:
>
> 1. speech not de= tected (because of SNR problem, etc.).  This will
> return no-in= put-timeout, just as it would for a speech recognizer.
>
> 2. = speech detected, neither too early (speech-too-early) nor too much
> = (too-much-speech-timeout), but still unusable by the training or
> ve= rification process.  Note that this could happen if the speech
>= passes the endpointer threshold but is too garbled or noisy to be of
&g= t; use to the verification engine.
> This case is not handled in MRCP= today.  I have added error code 011,
> "speech-not-usable", for= this case.
>
> 3. additional turns are needed:  the <= decision> result element can be
> used for this.  "undecided" was the value we chose to represent the
> case where the= engine did not yet have enough data to decide on a
> verification or= training result.  Note that training decisions can
> also be "a= ccepted" or "rejected" just like verification results -- the
> former= case means there is sufficient training data and the new
> voiceprin= t is acceptable.  The latter means there is sufficient
> trainin= g data but the new voiceprint is rejected, because for example
> it i= s too close to an existing voiceprint.
>
> -- dan
>
= > On Jan 11, 2009, at 7:06 PM, Nik Waldron wrote:
>
> > = I sent an email previously requesting information on how a speaker
> = > verification
> > system implementing MRCPv2 should cope in th= e situation, where there
> > was
> > insufficient or poor= quality speech arriving on the RTP audio
> > stream.  It
> > seemed
> > to me that was an area of some deficie= ncy in the specification.  I
> > received no
> > fee= dback other than one response saying that to his knowledge there
> &g= t; were
> > no
> > other implementers for Speaker Verific= ation.
> >
> > Below I outline the MRCPv2 exchanges for a= training operation:
> >
> >  C->S:  MRCP/2= ..0 207 START-SESSION 314161
> >          = Channel-Identifier:32AECB23433801@speakverify
> >  &nbs= p;       Repository-URI:http://www.example.com/voiceprintdbase/
> >          Voiceprint-Mode:tr= ain
> >          Voiceprint-Identifier:jo= hnsmith.voiceprint
> >
> >  S->C:  MRCP/2.0 82 314161 200 COMPLETE
> >        &n= bsp; Channel-Identifier:32AECB23433801@speakverify
> >
> >= ;  C->S:  MRCP/2.0 76 VERIFY 314162
> >   =       Channel-Identifier:32AECB23433801@speakverify
>= >
> >  S->C:  MRCP/2.0 85 314162 200 IN-PROGRESS=
> >          Channel-Identifier:32AECB23= 433801@speakverify
> >
> > The end-point detector show in= sufficient data (which is buffered),
> > or bad
> > signa= l quality (bad SNR for example).  Note that no START-OF-INPUT
> = > has NOT
> >
> > been sent although speech has begun.=
> >
> >  S->C:  MRCP/2.0 140 VERIFICATION-= COMPLETE 314162 COMPLETE
> >          Cha= nnel-Identifier:32AECB23433801@speakverify
> >          Completion-Cause:002 no-input-timeout
> >> > This is undesirable from my perspective since it gives the
&g= t; > impression to
> > the
> > client that no data has= been received (untrue in the insufficient data
> > case), and
= > > provides no distinction between this and the "bad data" case.&nbs= p; This
> > information
> > might be of utility to a call= -flow designer in an IVR system.
> >
> > I also note that= in the case of text-independent verifiers several
> > turns
&g= t; > worth of
> > data may be required for a verification. = ; Several rounds of "no input"
> > timeouts
> > would sur= ely be confusing to the client, yet this class of verifiers
> > ma= y
> > be unable
> > to generate and nlsml+xml response on= the nth dialog turn.
> >
> > The enrolment might then continue:
> >
> >  C->S:  MRCP/2.0 76= VERIFY 314163
> >          Channel-Ident= ifier:32AECB23433801@speakverify
> >
> >  S->C:&= nbsp; MRCP/2.0 85 314163 200 IN-PROGRESS
> >      &= nbsp;   Channel-Identifier:32AECB23433801@speakverify
> >
= > >  S->C:  MRCP/2.0 96 START-OF-INPUT 314163 IN-PROGRE= SS
> >          Channel-Identifier:32AECB= 23433801@speakverify
> >
> >  S->C:  MRCP/2= ..0 131 VERIFICATION-COMPLETE 314163 COMPLETE
> >    &nbs= p;     Channel-Identifier:32AECB23433801@speakverify
> >=           Completion-Cause:000 success
> >= ;
> >  C->S:  MRCP/2.0 76 VERIFY 314164
> >=           Channel-Identifier:32AECB23433801@speakverify
> >
> >&nb= sp; S->C:  MRCP/2.0 85 314164 200 IN-PROGRESS
> >  &= nbsp;       Channel-Identifier:32AECB23433801@speakverify> >
> >  S->C:  MRCP/2.0 96 START-OF-INPUT 31= 4164 IN-PROGRESS
> >          Channel-Ide= ntifier:32AECB23433801@speakverify
> >
> >  S->C= :  MRCP/2.0 131 VERIFICATION-COMPLETE 314164 COMPLETE
> >&nbs= p;         Channel-Identifier:32AECB23433801@speakverif= y
> >          Completion-Cause:000 succe= ss
> >
> >  C->S:  MRCP/2.0 81 END-SESSION = 314174
> >          Channel-Identifier:32= AECB23433801@speakverify
> >
> >  S->C:  MR= CP/2.0 82 314174 200 COMPLETE
> >          Channel-Identifier:32AECB23433801@speakverify
> >> > Since I received no responses (perhaps due to being close to th= e
> > holiday
> > season),
> > I will venture a = proposal for extending the RFC to include the bad
> > signal
&g= t; > cases
> > (+ indicates an addition, * a modification)
&= gt; >
> >  +------------+--------------------------
&g= t; > +---------------------------+
> >  | Cause-Code | Ca= use-Name              |
> > De= scription              |
> >&n= bsp; +------------+--------------------------
> > +--------------= -------------+
> >  | 000        | succe= ss                  | VERIFY> > or                |
> >  |            |=                      = ;     | VERIFY-FROM-
> > BUFFER      &nbs= p; |
> >  |            | =                     &nbs= p;   | request
> > completed        |> >  |            |   =                     &nbs= p; | successfully.  The
> > verify |
> >  |&nb= sp;           |          =                 | decision can
&= gt; > be          |
> >  | = ;           |                          | "accepted= ",
> > "rejected",  |
> >  |    &nb= sp;       |              =             | or
> > "undecided".&nb= sp;         |
> >  | 001    &= nbsp;   | error               =     | VERIFY
> > or          &= nbsp;     |
> >  |        &nb= sp;   |                  =         | VERIFY-FROM-
> > BUFFER   =     |
> >  |          &n= bsp; |                   =       | request
> > terminated        |
> >  |          &n= bsp; |                   =       | prematurely due to
> > a    &nbs= p; |
> >  |            | =                     &nbs= p;   | verification resource
> > or  |
> > = ; |            |        =                   | system
= > > error.            |
> >&n= bsp; | 002        | no-input-timeout    &nbs= p;   | VERIFY request
> > completed  |
> >&nbs= p; |            |       =                   | with no result due to
> > a  |
> >  |  =           |          &nbs= p;               | no-input-
> >= ; timeout.        |
> >  | 003  &n= bsp;     | too-much-speech-timeout  | VERIFY request
>= > completed  |
> >  |        &n= bsp;   |                 =         | result due to too
> > much  &n= bsp; |
> >  |            |&nbs= p;                     &n= bsp;   |
> > speech.           =       |
> >  | 004      &nbs= p; | speech-too-early        | VERIFY request
> > completed  |
> >  |    =         |            &nbs= p;             | with no result due
> &= gt; to    |
> >  |        &nb= sp;   |                  =         | spoke too
> > soon.    &nb= sp;     |
> > + | 005        | insu= fficient-speech      | VERIFY
> > or    &= nbsp;           |
> > + |    &= nbsp;       |             = ;             | VERIFY-FROM-
> > BUF= FER        |
> > + |       = ;     |                          | request
> > completed=         |
> > + |        =     |                &nbs= p;         | successfully but
> > had  &n= bsp;   |
> > + |            |&n= bsp;                     =     | insufficient speech
> > to    |
> = > + |            |      &nb= sp;                   | comple= te.  More
> > speech    |
> > + |  &n= bsp;         |           =               | will complete the
&g= t; > current |
> > + |            |                  &nb= sp;       | incremental
> > operation    = |
> > + | 006        | bad-speech   = ;           | VERIFY
> > or   =             |
> > + |   =         |            &nb= sp;             | VERIFY-FROM-
> > B= UFFER        |
> > + |      &nb= sp;     |                =           | request
> > completed  &= nbsp;     |
> > + |          &= nbsp; |                   = ;       | unsuccessfully,
> > the      |
> > + |           = |                    &nb= sp;     | speech quality was
> > too    |
&= gt; > + |            |     =                     |> > poor                &nbs= p;     |
> > *  | 007        | = buffer-empty            | VERIFY-FROM-
&g= t; > BUFFER        |
> >  |  &nb= sp;         |            =               | request completed with> > no |
> >  |          &n= bsp; |                          | result due to
> > empty   = ;   |
> >  |            = |                    &nbs= p;     |
> > buffer.          &= nbsp;       |
> > *  | 008     = ;   | out-of-sequence          | Verification=
> > operation    |
> >  |    &= nbsp;       |             = ;             | failed due
> > to&nb= sp;           |
> >  |   = ;         |            &n= bsp;             | out-of-sequence
> &g= t; method    |
> >  |            |              &nb= sp;           | invocations.  For
> >= ; example |
> >  |            = |                    &nbs= p;     | calling VERIFY
> > before    |
&g= t; >  |            |    &n= bsp;                     = | QUERY-
> > VOICEPRINT.        |
> >= ; *  | 009        | repository-uri-failure  = | Failure
> > accessing        |
> >=   |            |      &n= bsp;                   | Repos= itory
> > URI.          |
> > *  | 010        | repository-uri-missing&nbs= p; | Repository-uri is
> > not    |
> > = |            |        &= nbsp;                 |
> >= ; specified.                |
&g= t; > *  | 011        | voiceprint-id-missing&nb= sp;   | Voiceprint-
> > identification |
> >  = |            |        &nb= sp;                 | is not
>= ; > specified.        |
> > *  | 012&= nbsp;       | voiceprint-id-not-exist  | Voiceprint-> > identification |
> >  |       = ;     |                          | does not exist in
> >= the    |
> >  |         = ;   |                  &n= bsp;       | voiceprint
> > repository.   = ; |
> >  +------------+--------------------------
> &g= t; +---------------------------+
> >
> > Alternatively th= e new entries could be appended for compatibility.
> > The
>= > only
> > disadvantage to doing so would be that entries woul= d not be grouped
> > in the
> > table by category.
>= ; >
> > I'll happily accept any corrections to my understanding= , incase I have
> > misread
> > the spec, or feedback on = my suggestions.
> >
> >
> >
> >
>= > NIK WALDRON
> >
> > _______________________________________________
> > Speechsc mail= ing list
> > Speechsc@ietf.org
> > https://www.ietf.= org/mailman/listinfo/speechsc
> > Supplemental web site:
> > <http://www.standardstrack.com/ietf/speechsc>=
>
>
> ________________________________________________= ______________________
> This email has been scanned by the MessageLa= bs Email Security System.
> For more information please visit <= a target=3D"_blank" href=3D"http://www.messagelabs.com/email">http://www.me= ssagelabs.com/email
> ____________________________________= __________________________________
>
>
> This is an ema= il from Fujitsu Australia Limited, ABN 19 001 011 427. It is confidential to the o= rdinary user of the email address to which it was addressed and may contain= copyright and/or legally privileged information. No one else may read, pri= nt, store, copy or forward all or any of it or its attachments. If you rece= ive this email in error, please return to sender. Thank you.
> ______= ________________________________________________________________
> Th= is email has been scanned by the MessageLabs Email Security System.
>= For more information please visit http://www.messagelabs.com/email
> _______= _______________________________________________________________
> ___= ____________________________________________
> Speechsc mailing list<= br>> Speechsc@ietf.org
> = https://www.ietf.org/mailman/listinfo/speechsc
> Supplemental web= site:
> <http://www.standardstrack.com/ietf/speechsc>=

--0-69743759-1242054882=:3443--