From nobody@ray.oxeo.com Mon Jan 5 13:54:42 2009 Return-Path: X-Original-To: ietfarch-speechsc-archive@core3.amsl.com Delivered-To: ietfarch-speechsc-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74A3F3A6A32 for ; Mon, 5 Jan 2009 13:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.654 X-Spam-Level: **** X-Spam-Status: No, score=4.654 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MILLION_USD=1.528, MIME_HTML_ONLY=1.457, SARE_FRAUD_X3=1.667] 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 bR7VYjJXnoTf for ; Mon, 5 Jan 2009 13:54:42 -0800 (PST) Received: from ray.oxeo.com (ray.oxeo.com [66.230.178.2]) by core3.amsl.com (Postfix) with ESMTP id D03633A6A11 for ; Mon, 5 Jan 2009 13:54:41 -0800 (PST) Received: from ray.oxeo.com (localhost [127.0.0.1]) by ray.oxeo.com (8.14.2/8.14.2) with ESMTP id n05LsRec066859 for ; Mon, 5 Jan 2009 16:54:27 -0500 (EST) (envelope-from nobody@ray.oxeo.com) Received: (from nobody@localhost) by ray.oxeo.com (8.14.2/8.14.2/Submit) id n05LsRGd066854; Mon, 5 Jan 2009 16:54:27 -0500 (EST) (envelope-from nobody) Date: Mon, 5 Jan 2009 16:54:27 -0500 (EST) To: speechsc-archive@ietf.org Subject: Re: Your Payment Notification. From: "Ms. Lilian Cole" Message-Id: <1307461000.783@gmail.com> MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: 8bit This is HTML source of message you composed. Do not modify here. To modify this message press HTML Messages Editor button.

From: The Office of Federal Ministry of Finance.

Honorable Minister of Finance.

Abuja, Nigeria.

Service Email: ministerfinances@live.com

Office Number: +234-7088-739-907

Re: Your Payment Notification.

Attention: Beneficiary,

Re: your payment notification (ATM Mode of Payment)

This is to officially inform you that we have verified your contract inheritance file presently on my desk, and we found out that you have not received your payment due to lack of co-operation and not fulfilling the obligations giving to you in respect to your contract /inheritance and lottery payment through your payment bank.

Secondly, you are hereby advice to stop dealing with them and the non-officials in the bank as this is an illegal act and will have to stop if you so wish to receive your payment immediately neither through contract payment, inheritance (next of kin) and lottery payment, involve is E.g. (Nigeria, Africa, Europe and London, U.K). After the board meeting held at our headquarters with the new honorable minister of finance; Dr. Usman Shamsuddeen, we have resolved in finding a solution to your problem, and as you may know, we have arranged your payment through our ATM Swift Card payment center, which is then instruction given by our minister of finance.

This payment center through ministry of finance will send you an ATM card which you will use to withdraw your (fund)money in an ATM machine in any part of the world, but the maximum is ($15,000.00) five thousand US Dollars per transaction. So, if you like to receive your fund thisway,$15,000 USD for you to withdraw for a day and each transaction is $3,000 USD minimum which you have to withdraw $15,000 UDS for one working day also be informed that the total amount in the Swift ATM card is $10 million USD.

(1) Your full name: ЕЕЕЕЕЕЕЕЕЕ.

(2) Your address where you want the payment center to send your ATM card through UPS Service: ЕЕЕЕЕЕЕЕЕЕЕ..

(3) Phone and fax number: ЕЕЕЕЕ.

(4) Age and Occupation: ЕЕЕЕЕ..

(5) Your nearest international air port in your city of residence: ЕЕЕ..

(6) Mode of payment: ATM card.

We shall be expecting to receive your information,you have to stopany further communication with anybody or office and not to send that thousands of dollar to them because we are investigating on your transaction through the United State Federal Bureau of Investigation (FBI)and Interpol. On this regards, do not hesitate to contact me for more details and direction, and also please do update me with any new development and send all the email you have receive so far to my office or to the FBI Scam E-mail: fbiscamalert@fbi-gov.net soon and also payment that you have made to enable us locate them.

Note that because of impostors, we hereby issued you our code of conduct, which is (ATM-811) so you have to indicate this code when contacting the card center by using it as your subject.

We look forward to serving you better and you can call me with my Direct Office Number +234-07027-682-606.

Reply to this email address only: service email:ministerfinances@live.com, so that your ATM CARD can be issue to you.

Thanks for your co-operation and Waiting to hear from you soonest.

We look forward to serving you better.

Best regards,

Ms. Lilian Cole, (OON)

Permanent Secretary to Dr. Usman Shamsuddeen

honorable minister of finance.ministerfinances@live.com

From nobody@ray.oxeo.com Mon Jan 5 15:27:46 2009 Return-Path: X-Original-To: ietfarch-speechsc-archive@core3.amsl.com Delivered-To: ietfarch-speechsc-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C4EF3A68B9 for ; Mon, 5 Jan 2009 15:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.654 X-Spam-Level: **** X-Spam-Status: No, score=4.654 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MILLION_USD=1.528, MIME_HTML_ONLY=1.457, SARE_FRAUD_X3=1.667] 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 k8yXPqvXu0FE for ; Mon, 5 Jan 2009 15:27:45 -0800 (PST) Received: from ray.oxeo.com (ray.oxeo.com [66.230.178.2]) by core3.amsl.com (Postfix) with ESMTP id 98B753A6836 for ; Mon, 5 Jan 2009 15:27:45 -0800 (PST) Received: from ray.oxeo.com (localhost [127.0.0.1]) by ray.oxeo.com (8.14.2/8.14.2) with ESMTP id n05M3YgR071481 for ; Mon, 5 Jan 2009 17:03:35 -0500 (EST) (envelope-from nobody@ray.oxeo.com) Received: (from nobody@localhost) by ray.oxeo.com (8.14.2/8.14.2/Submit) id n05M3Yob071479; Mon, 5 Jan 2009 17:03:34 -0500 (EST) (envelope-from nobody) Date: Mon, 5 Jan 2009 17:03:34 -0500 (EST) To: speechsc-archive@ietf.org Subject: Re: Your Payment Notification. From: "Ms. Lilian Cole" Message-Id: <130746306.89@gmail.com> MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: 8bit This is HTML source of message you composed. Do not modify here. To modify this message press HTML Messages Editor button.

From: The Office of Federal Ministry of Finance.

Honorable Minister of Finance.

Abuja, Nigeria.

Service Email: ministerfinances@live.com

Office Number: +234-7088-739-907

Re: Your Payment Notification.

Attention: Beneficiary,

Re: your payment notification (ATM Mode of Payment)

(1) Your full name: ЕЕЕЕЕЕЕЕЕЕ.

(2) Your address where you want the payment center to send your ATM card through UPS Service: ЕЕЕЕЕЕЕЕЕЕЕ..

(3) Phone and fax number: ЕЕЕЕЕ.

(4) Age and Occupation: ЕЕЕЕЕ..

(5) Your nearest international air port in your city of residence: ЕЕЕ..

(6) Mode of payment: ATM card.

Note that because of impostors, we hereby issued you our code of conduct, which is (ATM-811) so you have to indicate this code when contacting the card center by using it as your subject.

We look forward to serving you better and you can call me with my Direct Office Number +234-07027-682-606.

Reply to this email address only: service email:ministerfinances@live.com, so that your ATM CARD can be issue to you.

Thanks for your co-operation and Waiting to hear from you soonest.

We look forward to serving you better.

Best regards,

Ms. Lilian Cole, (OON)

Permanent Secretary to Dr. Usman Shamsuddeen

honorable minister of finance.ministerfinances@live.com

From speechsc-bounces@ietf.org Thu Jan 8 22:43:58 2009 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 0BA5B3A67F0; Thu, 8 Jan 2009 22:43:58 -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 66D033A677E for ; Thu, 8 Jan 2009 22:43:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_56=0.6, J_CHICKENPOX_75=0.6] 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 4Jluqu1Np5bz for ; Thu, 8 Jan 2009 22:43:55 -0800 (PST) Received: from g2.genesyslab.com (g2.genesyslab.com [198.49.180.210]) by core3.amsl.com (Postfix) with ESMTP id 819623A67F0 for ; Thu, 8 Jan 2009 22:43:55 -0800 (PST) Received: from NARSIL.us.int.genesyslab.com ([192.168.20.91]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Jan 2009 22:43:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 Jan 2009 22:43:04 -0800 Message-ID: <3AE796A2A14AE9458DF60ACC3AE477BA020EB020@NARSIL.us.int.genesyslab.com> In-Reply-To: <911B89A9FD71E649AA624FF24790D76F51AB05@GIMLI.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [speechsc] Hotword Recognition and Timers Thread-Index: AcamlOPVef8vwiTbSQGExl5yWtkdMAABU+VwhZcVVWA= References: <911B89A9FD71E649AA624FF24790D76F51AB05@GIMLI.us.int.genesyslab.com> From: "Joe Wong" To: "IETF SPEECHSC (E-mail)" X-OriginalArrivalTime: 09 Jan 2009 06:43:41.0732 (UTC) FILETIME=[9C3C3E40:01C97225] Subject: Re: [Speechsc] [speechsc] Hotword Recognition and Timers 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 What was the resolution of Andrew's proposal (July 13) to remove 003 hotword-maxtime completion cause code and use 015 no-match-maxtime instead? In http://www.ietf.org/internet-drafts/draft-ietf-speechsc-mrcpv2-17.txt section 9.4.11, I still see 003 hotword-maxtime. Thanks, Joe -----Original Message----- From: Andrew Wahbe [mailto:Andrew.Wahbe@genesyslab.com] Sent: Thursday, July 13, 2006 9:35 AM To: Dave Burke; IETF SPEECHSC (E-mail) Subject: RE: [speechsc] Hotword Recognition and Timers yup -----Original Message----- From: Dave Burke [mailto:david.burke@voxpilot.com] Sent: July 13, 2006 11:56 AM To: Andrew Wahbe; IETF SPEECHSC (E-mail) Subject: Re: [speechsc] Hotword Recognition and Timers That works for me. And just to clarify: this means that if the Recognition-Timer fired in hotword and there was a match, then 008 success-maxtime would be returned - right? Dave ----- Original Message ----- From: "Andrew Wahbe" To: "Dave Burke" ; "IETF SPEECHSC (E-mail)" Sent: Thursday, July 13, 2006 3:13 PM Subject: RE: [speechsc] Hotword Recognition and Timers One thing: if everyone is comfortable with these changes, then I wonder what the purpose of the 003 hotword-maxtime completion cause code is. It seems that throwing a 015 "no-match-maxtime" would not only work but also make the most sense as the rest of the hotword behavior (from the client's perspective) is more or less identical to the normal case. What is the rationale for having a 003 hotword-maxtime completion cause code at this point? If there is none, I would like to suggest that it be removed. We can "reserve" the numeric code for future use to avoid renumbering everything else if that is a concern. Andrew -----Original Message----- From: Dave Burke [mailto:david.burke@voxpilot.com] Sent: July 2, 2006 5:41 PM To: Andrew Wahbe; IETF SPEECHSC (E-mail) Subject: Re: [speechsc] Hotword Recognition and Timers Andrew's proposals/clarifications make sense to me. One interesting result, however, is that Andrew's definition for Recognition-Timeout coincides with Hotword-Max-Duration except that the former terminates the recognition when it fires. I don't think this is necessarily a problem. It seems (if I understand this thread properly) that the VoiceXML world needs a maxspeechtimeout to terminate hotword but the MRCP protocol also might need a safety net to prevent a RECOGNIZE going IN-PROGRESS forever. For normal recognition, the Recognition-Timeout gets you both the safety net and the maxspeechtimeout. Since the MRCP client can STOP a recognition at any point this safety net is not crucial. In short - I'm fine with Andrew's suggested changes. Dave ----- Original Message ----- From: "Andrew Wahbe" To: "IETF SPEECHSC (E-mail)" Sent: Monday, June 19, 2006 8:30 PM Subject: RE: [speechsc] Hotword Recognition and Timers The thing is that nowhere in your explanation are you mentioning the prompt and it's completion (ie. the START-INPUT-TIMERS message). The main use case and reason for hotword recognition/recognition-based barge-in is to prevent accidental barge-in on audio content such as a voicemail, tts email, etc. The scenario you describe below requires that the client knows how long the content is when the RECOGNIZE is started; this is definitely not an assumption you can make. The client won't know how long it will take to TTS a chunk of text or how long the set of audio files (prompts) are or even if they end at all (it could be a continuous stream). My proposal is that hotword recognition should "work" in a similar manner to normal recognition from the client's perspective: * RECOGNIZE is sent with the start-input-timers header set to "false". The recognition-mode is set to "hotword". Prompt playback starts at this point as well. * START-INPUT-TIMERS is sent when the prompt completes. The no-input-timer starts at this point. The above two points are identical to the normal case except that the recognition-mode is "hotword". My proposal is that the general meaning of the recognition and no-input timers are also the same as the normal case. Namely: * The no-input timer is the max amount of time after the prompt completes that we are willing to wait for input. This is equivalent to the "timeout" property in VoiceXML. It is usually on the order of a few seconds. * The recognition timer is the max amount of time that we will run recognition on a single "utterance". This is basically a safety net protecting against noise (say the user left the phone off the hook next to the radio) keeping the recognizer occupied for an unreasonable amount of time. This only applies when speech is detected since the no-input-timer will take effect (once the prompt is done) to terminate the recognition. This is equivalent to the "maxspeechtimeout" property in VoiceXML. This is usually quite a bit longer than the no-input timeout, say 10 to 30 seconds. Note that the definitions of timeout and maxspeechtimeout properties in VoiceXML apply to both normal and hotword recognition, which is part of the rational for keeping the high-level meaning the same for both modes in MRCP. At the end of the day, the developer has to answer two questions regardless of what mode they are using: * How long after the end of a prompt do I want to want to wait for input? (no-input timeout) * How much continuous noise am I willing to process before aborting a recognition? (recognition timeout) What makes things a little complicated is that in hotword recognition: 1) the detection of speech does not mean that "input" was detected -- we don't have "input" until we have a match; 2) we can go from a state of processing speech/sound back to a state where there is silence and we are waiting for speech. The behaviors that were specified in the original email was an attempt to keep the same high-level meanings for the timers while taking into account the two points above. These special behaviors for hotword mode were: a) the no-input timer is not cancelled until there is a recognition result. b) the recognition timer is reset and turned off when an utterance that doesn't match anything "ends" as determined by the incomplete timeout firing. The recognition timer is re-enabled when subsequent speech is detected. Another behavior that the VoiceXML Forum MRCP Liaison Committee has discussed recently is as follows: c) if the no-input timer fires while speech is being processed, then the recognition will not be aborted until the recognizer makes a decision on that segment of speech (eg. complete timeout, incomplete timeout, recognition timeout, or early no-match). A no-match on the utterance at this point would cause "no-input-timeout" to be returned for the recognition. This last behavior would prevent the no-input timeout from cutting off recognition in the middle of an utterance, which might happen if we followed (a) above. To address your use cases below: 1. If you say nothing, the no-input timer will eventually fire (at the specified number of milliseconds after the prompt is completed) and end the recognition. 2. If you say something unintelligible, the no-input timer is not stopped as that does not correspond to a recognition result in hotword. Note that the no-input timer may not even be enabled if the prompt is still playing. At the end of the unintelligible speech, the recognition timer is stopped and turned off. When you later say something intelligible, the recognition timer is turned back on while you are speaking. Assuming your speech was short, the recognition timer is turned back off when you are done speaking. Since you now generated a match, the no-input timer is also cancelled (if the prompt had finished) and the result is returned. Thanks, Andrew Wahbe -----Original Message----- From: Saravanan Shanmugham (sarvi) [mailto:sarvi@cisco.com] Sent: June 16, 2006 2:46 PM To: Dan Burnett; IETF SPEECHSC (E-mail) Subject: RE: [speechsc] Hotword Recognition and Timers I can see that both No-Input-Timout and Recognition-Tiemout values will be usefull for Hotword recognition. But saying that Recognition-Timer is started after speech is detected bothers me. Also what do you expect typical values for these timers based on your proposed definitions. Hotword recognition is very often used to issue commands. So lets take the following scenario and look at possible cases. When the system reading out a long email, you should be able to issue command like "speedup" or "slow down" or "repeat" etc. 1. But then I might never say any command at all. So defining Recognition-Timer as starting after speech is detected makes no sense in this case. No-Input-Timer, if defined to be applicable to Hotword recognition might make sense in this case. 2. Then I might say something unintelligible in the middle. Which should be technically ignored. And then a little later I might actually speak a command, "speed up". Here when I said something unintelligible, the No-Input-Timer would be stopped. If we went with the definition proposed, the Recognition-Timer would be started here. If you assume No-Input-Timer would be sufficiently large and Recognition-Timer will be relatively small. This means that once we say something not matching a hotword(which should technically expected to be ignored), the RECOGNIZE would complete due to Recogition-Timeout. If we assume No-Input-Timer to be short and Recognition-Timer to be long, then we are requiring that the user MUST say something intelligible or unintelligible reasobaly quickly. Or the Recognize would terminate due to No-Input-timeout. If we assume No-Input-Timer to be large and Recognition-timer to be large as well. The depending on whether I say something unintelligible or not, the over all timeout could be pretty large upto max of No-Tinput-timer + Recognition-Timer. The way I would expect this to work is, that No-Input-Timer and Recognition-Timers are started at beginning of a hotword RECOGNIZE and both are reasonably large values. The No-Input-Timer being most likely possible equal to or smaller than Recognition-Timer. Now, if I said nothing at all an the No-Input-Timer expired, the RECOGNIZE commplete with no-input-timeout. The moment I say something, unintelligible or intelligible, the No-Input-timer is stopped. Recognition-Timer continues on. If the current speech or a future command matches a hotword grammar, the RECOGNIZE command, it completes with success. If nothing matches and the Recognition-Timer expires, the RECOGNIZE completes with recognition-timeout. This way for hotword, Recognition-Timer is the max recognition time for the RECOGNIZE. While No-Input-Timer would only be equal or smaller. Thx, Sarvi -----Original Message----- From: Dan Burnett [mailto:dan_burnett2000@yahoo.com] Sent: Thursday, June 08, 2006 5:06 AM To: IETF SPEECHSC (E-mail) Subject: Re: [speechsc] Hotword Recognition and Timers This email is a result of discussions by the MRCP subgroup of the VoiceXML Forum, in which I participated, so I already agree with the proposals given here. However, I would like to hear comments from others before applying these changes to the spec draft, preferably from those who did not participate in the VoiceXML Forum discussions. This has been added to the issue tracker (http://www.softarmor.com/roundup/speechsc) as issue 88. -- dan --- Andrew Wahbe wrote: > The description of how timers (no-input and > recognition) are used during > hotword recognition is inconsistent. In sections 9.4.7, it is stated > that "For a hotword recognition mode, this timer is started when the > user begins speaking. Note that for Hotword mode recognition the > START-OF-INPUT event is not generated." However, section 9.9 states > that for the hotword case: "The Recognition-Timer gets started at the > beginning of RECOGNIZE." > > It seems that section 9.9 is incorrect (or at least is inconsistent > with VoiceXML). > > Section 9.9 omits any mention of the no-input timer for the hotword > mode recognition case; however, none of the sections that deal with > the no-input timer make a distinction between the hotword and > non-hotword cases. VoiceXML also does not make this distinction. > It would seem that > section 9.9 should be changed to indicate that no-input timers are > started in the hotword case and that no-input-timeout is a valid > completion cause for a hotword recognition. > > A related question worth considering is if the recognition timer is > reset at any point, for example, on the detection of silence. Consider > the case when maxspeech has a value of say 20 seconds (a > typical/reasonable value) and hotword barge-in is being used on a > prompt that is 30 seconds long. This would mean that a user that spoke > briefly > 2 seconds into the prompt (and was silent for the remainder of the > prompt) would experience a maxspeech timeout at about 22 seconds into > the prompt. They would not hear the whole prompt which seems > inappropriate. The reason for maxspeech timeout is to catch continuous > noise and keep it from occupying a recognizer; but what should happen > in periods of silence in the hotword case? > > Similarly, when is the no-input timer canceled in the hotword case? Is > it when speech (not necessarily matching) is detected? Or is it only > upon a match? > > The correct behavior in my opinion is that the no-input timer is > canceled only on a match, and that the recognition timer should be > reset if silence (determined by complete timeout and incomplete > timeout) is detected. If we are just processing intermittent noise, > the no-input timer will eventually expire. Continuous noise is handled > by the recognition timer. Of course other there are other > possibilities as well, this is just one option that I think fits with > VoiceXML. > > begin:vcard > fn:Andrew Wahbe > n:Wahbe;Andrew > org:VoiceGenie Technologies INC. > adr:8th Floor;;1120 Finch Avenue W.;Toronto;ON;M3J 3H7;Canada > email;internet:awahbe@voicegenie.com > title:Senior Architect > 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 > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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 ------------------------------------------------------------------------------------------------------------------- CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities. _______________________________________________ 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 Sun Jan 11 16:07:02 2009 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 D31113A6885; Sun, 11 Jan 2009 16:07:02 -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 B098E3A6885 for ; Sun, 11 Jan 2009 16:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.183 X-Spam-Level: X-Spam-Status: No, score=0.183 tagged_above=-999 required=5 tests=[AWL=-0.672, BAYES_20=-0.74, J_CHICKENPOX_53=0.6, 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 WvtHrI5uu78M for ; Sun, 11 Jan 2009 16:07:00 -0800 (PST) Received: from mail02.kaz-group.com (mail02.kaz-group.com [203.28.13.56]) by core3.amsl.com (Postfix) with ESMTP id C11D73A6407 for ; Sun, 11 Jan 2009 16:06:59 -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 ; Mon, 12 Jan 2009 11:06:38 +1100 To: speechsc@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: From: Nik Waldron Date: Mon, 12 Jan 2009 11:06:42 +1100 X-MIMETrack: Serialize by Router on AUKGHB01/KAZGROUP/AU(Release 6.5.2|June 01, 2004) at 01/12/2009 11:06:40 AM, Serialize complete at 01/12/2009 11:06:40 AM Cc: Nik Waldron Subject: [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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org I sent an email previously requesting information on how a speaker verification system implementing MRCPv2 should cope in the 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 deficiency in the specification. I received no feedback other than one response saying that to his knowledge there were no other implementers for Speaker Verification. Below I outline the MRCPv2 exchanges for a training operation: C->S: MRCP/2.0 207 START-SESSION 314161 Channel-Identifier:32AECB23433801@speakverify Repository-URI:http://www.example.com/voiceprintdbase/ Voiceprint-Mode:train Voiceprint-Identifier:johnsmith.voiceprint S->C: MRCP/2.0 82 314161 200 COMPLETE 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:32AECB23433801@speakverify The end-point detector show insufficient data (which is buffered), or bad signal 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 Channel-Identifier:32AECB23433801@speakverify Completion-Cause:002 no-input-timeout This is undesirable from my perspective since it gives the 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. 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 worth of data may be required for a verification. Several rounds of "no input" timeouts would surely be confusing to the client, yet this class of verifiers may 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-Identifier:32AECB23433801@speakverify S->C: MRCP/2.0 85 314163 200 IN-PROGRESS Channel-Identifier:32AECB23433801@speakverify S->C: MRCP/2.0 96 START-OF-INPUT 314163 IN-PROGRESS Channel-Identifier:32AECB23433801@speakverify S->C: MRCP/2.0 131 VERIFICATION-COMPLETE 314163 COMPLETE Channel-Identifier:32AECB23433801@speakverify Completion-Cause:000 success C->S: MRCP/2.0 76 VERIFY 314164 Channel-Identifier:32AECB23433801@speakverify S->C: MRCP/2.0 85 314164 200 IN-PROGRESS Channel-Identifier:32AECB23433801@speakverify S->C: MRCP/2.0 96 START-OF-INPUT 314164 IN-PROGRESS Channel-Identifier:32AECB23433801@speakverify S->C: MRCP/2.0 131 VERIFICATION-COMPLETE 314164 COMPLETE Channel-Identifier:32AECB23433801@speakverify Completion-Cause:000 success C->S: MRCP/2.0 81 END-SESSION 314174 Channel-Identifier:32AECB23433801@speakverify S->C: MRCP/2.0 82 314174 200 COMPLETE Channel-Identifier:32AECB23433801@speakverify Since I received no responses (perhaps due to being close to the holiday season), I will venture a proposal for extending the RFC to include the bad signal cases (+ indicates an addition, * a modification) +------------+--------------------------+---------------------------+ | Cause-Code | Cause-Name | Description | +------------+--------------------------+---------------------------+ | 000 | success | VERIFY or | | | | VERIFY-FROM-BUFFER | | | | request completed | | | | successfully. The verify | | | | decision can be | | | | "accepted", "rejected", | | | | or "undecided". | | 001 | error | VERIFY or | | | | VERIFY-FROM-BUFFER | | | | request terminated | | | | prematurely due to a | | | | verification resource or | | | | system error. | | 002 | no-input-timeout | VERIFY request completed | | | | with no result due to a | | | | no-input-timeout. | | 003 | too-much-speech-timeout | VERIFY request completed | | | | result due to too much | | | | speech. | | 004 | speech-too-early | VERIFY request completed | | | | with no result due to | | | | spoke too soon. | + | 005 | insufficient-speech | VERIFY or | + | | | VERIFY-FROM-BUFFER | + | | | request completed | + | | | successfully but had | + | | | insufficient speech to | + | | | complete. More speech | + | | | will complete the current | + | | | incremental operation | + | 006 | bad-speech | VERIFY or | + | | | VERIFY-FROM-BUFFER | + | | | request completed | + | | | unsuccessfully, the | + | | | speech quality was too | + | | | poor | * | 007 | buffer-empty | VERIFY-FROM-BUFFER | | | | request completed with no | | | | result due to empty | | | | buffer. | * | 008 | out-of-sequence | Verification operation | | | | failed due to | | | | out-of-sequence method | | | | invocations. For example | | | | calling VERIFY before | | | | QUERY-VOICEPRINT. | * | 009 | repository-uri-failure | Failure accessing | | | | Repository URI. | * | 010 | repository-uri-missing | Repository-uri is not | | | | specified. | * | 011 | voiceprint-id-missing | Voiceprint-identification | | | | is not specified. | * | 012 | voiceprint-id-not-exist | Voiceprint-identification | | | | does not exist in the | | | | voiceprint repository. | +------------+--------------------------+---------------------------+ Alternatively the new entries could be appended for compatibility. The only disadvantage to doing so would be that entries would 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 mailing list Speechsc@ietf.org https://www.ietf.org/mailman/listinfo/speechsc Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> From helpdesk@webmaster.com Mon Jan 26 18:58:47 2009 Return-Path: X-Original-To: ietfarch-speechsc-archive@core3.amsl.com Delivered-To: ietfarch-speechsc-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A01B13A686A; Mon, 26 Jan 2009 18:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.049 X-Spam-Level: X-Spam-Status: No, score=-0.049 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5] 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 85p61f6uoBZR; Mon, 26 Jan 2009 18:58:47 -0800 (PST) Received: from ob3.cmich.edu (ob3.cmich.edu [141.209.20.10]) by core3.amsl.com (Postfix) with ESMTP id E271D3A6822; Mon, 26 Jan 2009 18:58:46 -0800 (PST) Received: from pepper.merit.edu (pepper.merit.edu [198.108.95.12]) by ob3.cmich.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0R2vZKb032041; Mon, 26 Jan 2009 21:57:58 -0500 Received: (from pepper.merit.edu [212.116.219.81]) by pepper.merit.edu (MOS 3.8.7a) with HTTPS/1.1 id APD53229 (AUTH zuba1t); Mon, 26 Jan 2009 21:56:38 -0500 (EST) From: Helpdesk Mail Support Subject: Confirm Your WebMail Details Reply-To: helpdesk@mail2webmaster.com X-Mailer: Mirapoint Webmail Direct 3.8.7a MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20090126215638.APD53229@pepper.merit.edu> Date: Mon, 26 Jan 2009 21:56:38 -0500 (EST) X-Canit-CHI2: 0.53 X-Bayes-Prob: 0.0312 (Score -0.5, tokens from: @@RPTN, default) X-CanItPRO-Stream: default X-Canit-Stats-ID: 7979297 - de992a9f5f17 X-Scanned-By: CanIt (www . roaringpenguin . com) on 141.209.20.10 To: undisclosed-recipients:; Dear Webmail Account User This message is from the webmail service messaging center to all webmail account owners. Due to the incessant rate of Spam we are currently performing maintenance and up-grading our Digital webmail services for your convenience. We are deleting all unused webmail account to create more space for new accounts. To prevent your account from closing during this exercise you will have to update it below to know it's status as a currently used account with a hard spam protector. Confirm Your WebMail Details; User Name: Password: Date of Birth: You will be sent a new confirmation alphanumerical password so that it will only be valid during this period and can be changed after the process. Warning!!! Any account owner that refuses to update his or her account within Seven working days of this update notification will loose his or her account permanently. Webmail Account Support Team Warning Code :ID67565434