From dburnett@voxeo.com Tue May 5 13:27:16 2009 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 E3D143A6A47 for ; Tue, 5 May 2009 13:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 hFFtW5k2xjti for ; Tue, 5 May 2009 13:27:15 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with SMTP id 739933A69BB for ; Tue, 5 May 2009 13:27:14 -0700 (PDT) Received: from 182.sub-70-214-140.myvzw.com (account dburnett [70.214.140.182] verified) by voxeo.com (CommuniGate Pro SMTP 5.2.3) with ESMTPSA id 41553298; Tue, 05 May 2009 20:28:33 +0000 Message-Id: From: Dan Burnett To: Joe Wong In-Reply-To: <3AE796A2A14AE9458DF60ACC3AE477BA020EB020@NARSIL.us.int.genesyslab.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 5 May 2009 16:28:26 -0400 References: <911B89A9FD71E649AA624FF24790D76F51AB05@GIMLI.us.int.genesyslab.com> <3AE796A2A14AE9458DF60ACC3AE477BA020EB020@NARSIL.us.int.genesyslab.com> X-Mailer: Apple Mail (2.930.3) Cc: "IETF SPEECHSC \(E-mail\)" 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: , X-List-Received-Date: Tue, 05 May 2009 20:27:17 -0000 Joe, Issue 88 was resolved in Draft 13. The change notes say ====== - Issue 88: Moved text about the No-Input and Recognition timers in 9.9 from the beginning of the Non-Hotword mode section before the two modes to be clear that it applies to both modes. Added bullet in 9.9 hotword mode section about what to do when the No-Input timer expires. Added bullet in 9.9 hotword mode section about cancelling and restarting the Recognition timer. - Issue 88: Aligned text in 9.4.7 and 9.9 by doing the following: -- removed text in 9.4.7 describing how the timer behaves, since that is already described described in section 9.9 where it belongs. This section should only describe how to set the header value. -- removed first bullet point in hotword description in 9.9. Added new paragraph there noting that the START-OF-INPUT event is not generated when speech/DTMF is detected. ====== These specific changes were made after much discussion in order to better align hotword mode in MRCP with hotword mode in VoiceXML. The key in both cases is that hotword mode doesn't allow a no-match/reject to be returned, because any failure to match is treated as if the person has not spoken. -- dan On Jan 9, 2009, at 1:43 AM, Joe Wong wrote: > 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 dburnett@voxeo.com Tue May 5 13:28:01 2009 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 3BC083A6D1A for ; Tue, 5 May 2009 13:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.955 X-Spam-Level: X-Spam-Status: No, score=-0.955 tagged_above=-999 required=5 tests=[AWL=1.044, BAYES_00=-2.599, J_CHICKENPOX_53=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 tAnjAp77dpcC for ; Tue, 5 May 2009 13:28:00 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with SMTP id D39CB3A6D09 for ; Tue, 5 May 2009 13:27:59 -0700 (PDT) Received: from 182.sub-70-214-140.myvzw.com (account dburnett [70.214.140.182] verified) by voxeo.com (CommuniGate Pro SMTP 5.2.3) with ESMTPSA id 41553331; Tue, 05 May 2009 20:29:25 +0000 Message-Id: <9207B042-ECA6-4156-A656-C171F0CECE08@voxeo.com> From: Dan Burnett To: Nik Waldron In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 5 May 2009 16:29:21 -0400 References: X-Mailer: Apple Mail (2.930.3) 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: Tue, 05 May 2009 20:28:01 -0000 Nik, Thanks for your email. There are three cases in what you have described: 1. speech not detected (because of SNR problem, etc.). This will return no-input-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 verification process. Note that this could happen if the speech passes the endpointer threshold but is too garbled or noisy to be of 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 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 "accepted" or "rejected" just like verification results -- the former case means there is sufficient training data and the new voiceprint is acceptable. The latter means there is sufficient training data but the new voiceprint is rejected, because for example it is 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 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 dburnett@voxeo.com Tue May 5 13:28:34 2009 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 8C6463A6A47 for ; Tue, 5 May 2009 13:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=0.822, 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 I05tUG-HcK2K for ; Tue, 5 May 2009 13:28:33 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with SMTP id 8A54E3A69BB for ; Tue, 5 May 2009 13:28:33 -0700 (PDT) Received: from 182.sub-70-214-140.myvzw.com (account dburnett [70.214.140.182] verified) by voxeo.com (CommuniGate Pro SMTP 5.2.3) with ESMTPSA id 41553338 for speechsc@ietf.org; Tue, 05 May 2009 20:29:59 +0000 Message-Id: <7F91D49D-4D7A-41B0-9B67-C7D112F07A5E@voxeo.com> From: Dan Burnett To: speechsc@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 5 May 2009 16:29:55 -0400 X-Mailer: Apple Mail (2.930.3) Subject: [Speechsc] Changes from draft -17 to draft -18 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: Tue, 05 May 2009 20:28:34 -0000 Group, Here are the changes in draft-18 (just submitted). -- dan - 1: Clarified relationship with RTSP. - 2.1: Added definition of "endpointing". - In Section 5, changed "However, to assist in compact representations, MRCPv2 also allows other character sets such as ISO 8859-1 to be used when desired." to "However, to assist in compact representations, MRCPv2 also allows message content to be represented in other character sets such as ISO 8859-1." In the context of its paragraph, this change clarifies that message header values are always in UTF-8. - In Section 6.2, changed "It MUST be possible to combine multiple headers of the same name into one "header:value" pair without changing the semantics of the message, by appending each subsequent value to the first, each separated by a comma." to "Since vendor-specific parameters may be order-dependent, it MUST be possible to combine multiple headers of the same name into one "header:value" pair without changing the semantics of the message, by appending each subsequent value to the first, each separated by a comma.". - In 6.2.5, changed "acceptable character set" to "acceptable character sets". - In 6.2.11, changed "the receiver MAY ignore the content of the message body." to "the receiver MUST ignore the content of the message body." - In 6.3, changed "(a=resultformat:application/emma-xml)" to "(a=resultformat:application/emma+xml)" - 8.4.13, 9.4.21, 10.4.6: changed "all anticipated access protocols" to "any access protocol". Changed "is alphanumeric" to be "is UTF-8". Also, in the ABNF changed "alphanum" to be "UTFCHAR". - 8.5.1, 8.5.2, 9.5.1, 9.9: after first mention of text/uri-list, added reference to RFC 2483. - 9.4.6: changed 'Completion-Status of "002 no-input-timeout"' to 'Completion-Cause of "no-input-timeout"' - 9.4.8: changed "in the form of a URI returned" to "by returning a URI". - 9.16: changed "has no effect on the second attempt." to "has no effect the second time". - 10.6: changed "any other URI schemes supported by the server SHOULD employ integrity and confidentiality on the data transfer (e.g. FTPS)" to "any protocols used for dereferencing SHOULD employ integrity and confidentiality" - 11.4.16: added new failure Completion-Cause of "speech-not-usable". - 13.5: changed "We make the assumption that '>' is not a valid character in a URI according to RFC3986." to "'>' must be percent encoded in URIs according to RFC3986." - 13.5.2: ***section deleted***. This media type already exists. - 13.6: changed "The URLs defined here provide an addressing or referencing mechanism only." to "The URIs defined here provide an identification mechanism only." Added a few within-document references and made a modest number of minor, non-functional wording changes, mainly in introductory sections. Plus fixed the inevitable typos. From root@core3.amsl.com Tue May 5 13:30:01 2009 Return-Path: X-Original-To: speechsc@ietf.org Delivered-To: speechsc@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 877383A6BC7; Tue, 5 May 2009 13:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090505203001.877383A6BC7@core3.amsl.com> Date: Tue, 5 May 2009 13:30:01 -0700 (PDT) Cc: speechsc@ietf.org Subject: [Speechsc] I-D Action:draft-ietf-speechsc-mrcpv2-18.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: , X-List-Received-Date: Tue, 05 May 2009 20:30:01 -0000 --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-18.txt Pages : 215 Date : 2009-05-05 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 other protocols, such as Session Initiation Protocol (SIP) to rendezvous MRCPv2 clients and servers and manage sessions between them, and the Session Description Protocol (SDP) to describe, discover and exchange capabilities. 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-18.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-18.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-05132010.I-D@ietf.org> --NextPart-- From slawomir.testowy@gmail.com Wed May 6 00:25:21 2009 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 594563A6951 for ; Wed, 6 May 2009 00:25:19 -0700 (PDT) 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 NfJPBPWgyd1J for ; Wed, 6 May 2009 00:25:14 -0700 (PDT) Received: from mail-bw0-f174.google.com (mail-bw0-f174.google.com [209.85.218.174]) by core3.amsl.com (Postfix) with ESMTP id A87163A69D3 for ; Wed, 6 May 2009 00:25:09 -0700 (PDT) Received: by bwz22 with SMTP id 22so1847772bwz.37 for ; Wed, 06 May 2009 00:26:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=rOzCu2+0H+4KvTtpDTtx7H0Z3+OWSNRGS6mEHPM4BcE=; b=lz1kdIVHfTDyfkqZFyMRml4iY8ybAjPEvd0yqDZhwk9skKDh09JMrvpcFPsI1k1VpP Zs8yS2T63Rt68aRK9SnzX6UQUxDryn1cKut34sLZr4Kp1bkoO6GLeZRTihNiNWFH/mmv 1p/3d1Zky2yTWbLBb/D3DRsrV1BUk7PDVi5JA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=bGJB1dUIk0ll3IqA9KCURDKqF3PlE3LTDq3uPn/uNzX9cHmEi9LsbnMPLKi1OPAt+r xjl0F/eKFR9ARN6M2p7E5on1SpfL1sTEYd5FYqHFFYxBNEwlCuX32IgtTLkZHhxXsOC/ 2+pi/atpuXXuS/9HIjKPRc14l9LzSvMoWk6jE= MIME-Version: 1.0 Received: by 10.204.72.129 with SMTP id m1mr935059bkj.61.1241594792908; Wed, 06 May 2009 00:26:32 -0700 (PDT) Date: Wed, 6 May 2009 09:26:32 +0200 Message-ID: <8681d1580905060026l3763d4e1g40f42e8299af59aa@mail.gmail.com> From: Slawomir Testowy To: speechsc@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Speechsc] Ambiguous description of BARGE-IN-OCCURRED in section 8.8 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 07:26:54 -0000 Hi, I am reading draft-18 and I find description of BARGE-IN-0CCURRED method hard to understand. > 8.8. BARGE-IN-OCCURED There is a typo. > If a "SPEAK" request is active with kill-on-barge-in enabled, and the > BARGE-IN-OCCURRED event is received, the synthesizer MUST immediately > stop streaming out audio. Must the synthesizer stop streaming out audio if a "SPEAK" request is in "PAUSED" state? I couldn't find a definition of "active SPEAK request". I guess it is a current processed "SPEAK"? > It MUST also terminate any speech requests > queued behind the current active one, irrespective of whether they > have barge-in enabled or not. Does this statement depend on previous one? I.e. must the synthesizer terminate all speech requests queued behind the current one regardless of kill-on-barge-in enabled in active "SPEAK"? > If a barge-in-able "SPEAK" request was > playing and it was terminated, the response MUST contain the an > active-request-list header listing the request-ids of all "SPEAK" > requests that were terminated. The server generates no > "SPEAK-COMPLETE" events for these requests. That sounds good. However, example in section 14.1 says something different: > C->S: MRCP/2.0 289 SPEAK 543259 > Channel-Identifier:32AECB23433801@speechsynth > Kill-On-Barge-In:true > Content-Type:application/ssml+xml > Content-Length:418 > Content-Length:... [...] > S->C: MRCP/2.0 52 543259 200 IN-PROGRESS > Channel-Identifier:32AECB23433801@speechsynth > Speech-Marker:timestamp=857207696314 [...] > C->S: MRCP/2.0 69 BARGE-IN-OCCURRED 543259 > Channel-Identifier:32AECB23433801@speechsynth > Proxy-Sync-Id:987654321 > > S->C: MRCP/2.0 72 543259 200 COMPLETE > Channel-Identifier:32AECB23433801@speechsynth > Active-Request-Id-List:543258 > Speech-Marker:timestamp=857206096314 > > S->C: MRCP/2.0 73 SPEAK-COMPLETE 543259 COMPLETE > Channel-Identifier:32AECB23433801@speechsynth > Completion-Cause:001 barge-in > Speech-Marker:timestamp=857207685213 Moreover, request BARGE-IN-OCCURRED has the same request-id as previous SPEAK. Is this correct? -- Slawomir Testowy From dburnett@voxeo.com Wed May 6 10:33:02 2009 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 0F4003A6FDC for ; Wed, 6 May 2009 10:33:02 -0700 (PDT) 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 jlMVYXy-pRtZ for ; Wed, 6 May 2009 10:32:54 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with SMTP id 7A88A3A6E93 for ; Wed, 6 May 2009 10:27:46 -0700 (PDT) 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 41582355; Wed, 06 May 2009 17:29:07 +0000 Message-Id: <62166606-B738-41CC-A7A0-58F681EFA6DA@voxeo.com> From: Dan Burnett To: Slawomir Testowy In-Reply-To: <8681d1580905060026l3763d4e1g40f42e8299af59aa@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 6 May 2009 13:29:02 -0400 References: <8681d1580905060026l3763d4e1g40f42e8299af59aa@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: speechsc@ietf.org Subject: Re: [Speechsc] Ambiguous description of BARGE-IN-OCCURRED in section 8.8 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 17:33:02 -0000 On May 6, 2009, at 3:26 AM, Slawomir Testowy wrote: > Hi, > > I am reading draft-18 and I find description of BARGE-IN-0CCURRED > method hard to understand. > >> 8.8. BARGE-IN-OCCURED > > There is a typo. Thanks. > > >> If a "SPEAK" request is active with kill-on-barge-in enabled, and the >> BARGE-IN-OCCURRED event is received, the synthesizer MUST immediately >> stop streaming out audio. > > Must the synthesizer stop streaming out audio if a "SPEAK" request is > in "PAUSED" state? Yes. > > I couldn't find a definition of "active SPEAK request". I guess it is > a current processed "SPEAK"? I agree that the current use of the word "active" is a bit confusing. It is clearer if you understand the point of the BARGE-IN-OCCURRED event. When an ASR engine detects speech, if a prompt (audio) is being played the client usually wants to cancel the audio being played. The kill-on-barge-in parameter and BARGE-IN-OCCURRED event allow for this. Since the audio is interrupted (but did not stop due to a failure in the synthesis resource), it has a normal termination, meaning that there is a SPEAK-COMPLETE generated for this bit of audio. Anything queued up after it (PENDING), however, is removed from the queue since the occurrence of speech during a prompt usually will cause a change in the dialog direction that can invalidate all queued prompts. The reason no SPEAK-COMPLETE is sent for these removed PENDING requests is to distinguish them from the case where a failure occurs during the playout of the current audio. In that case (see Section 8.6, next-to-last paragraph), each PENDING request stops with a SPEAK-COMPLETE (with Completion-Cause of "cancelled"). So, in the text above "active" means either IN-PROGRESS or PAUSED. > > >> It MUST also terminate any speech requests >> queued behind the current active one, irrespective of whether they >> have barge-in enabled or not. > > Does this statement depend on previous one? I.e. must the synthesizer > terminate all speech > requests queued behind the current one regardless of kill-on-barge-in > enabled in active "SPEAK"? It depends on the previous statement. If kill-on-barge-in is enabled for the currently active SPEAK request, then all queued (PENDING) requests are terminated regardless of whether or not they have kill-on- barge-in enabled. > > >> If a barge-in-able "SPEAK" request was >> playing and it was terminated, the response MUST contain the an >> active-request-list header listing the request-ids of all "SPEAK" >> requests that were terminated. The server generates no >> "SPEAK-COMPLETE" events for these requests. > > That sounds good. However, example in section 14.1 says something > different: Yes, the wording above is unclear. The server generates a SPEAK- COMPLETE event for the barged-in SPEAK request with a completion-cause of "barge-in" so the client knows that the audio was stopped, and for that reason. However, no SPEAK-COMPLETE messages are sent for the queued messages that were terminated because of the barge-in. > > >> C->S: MRCP/2.0 289 SPEAK 543259 >> Channel-Identifier:32AECB23433801@speechsynth >> Kill-On-Barge-In:true >> Content-Type:application/ssml+xml >> Content-Length:418 >> Content-Length:... > > [...] > >> S->C: MRCP/2.0 52 543259 200 IN-PROGRESS >> Channel-Identifier:32AECB23433801@speechsynth >> Speech-Marker:timestamp=857207696314 > > [...] > >> C->S: MRCP/2.0 69 BARGE-IN-OCCURRED 543259 >> Channel-Identifier:32AECB23433801@speechsynth >> Proxy-Sync-Id:987654321 >> >> S->C: MRCP/2.0 72 543259 200 COMPLETE >> Channel-Identifier:32AECB23433801@speechsynth >> Active-Request-Id-List:543258 >> Speech-Marker:timestamp=857206096314 >> >> S->C: MRCP/2.0 73 SPEAK-COMPLETE 543259 COMPLETE >> Channel-Identifier:32AECB23433801@speechsynth >> Completion-Cause:001 barge-in >> Speech-Marker:timestamp=857207685213 > > Moreover, request BARGE-IN-OCCURRED has the same request-id > as previous SPEAK. Is this correct? Oops, no, that's a typo. It should have a different request-id. > > > -- > Slawomir Testowy > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www.ietf.org/mailman/listinfo/speechsc > Supplemental web site: > <http://www.standardstrack.com/ietf/speechsc> From slawomir.testowy@gmail.com Fri May 8 03:59:29 2009 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 1504E3A6F95 for ; Fri, 8 May 2009 03:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWReXpom5cGw for ; Fri, 8 May 2009 03:59:28 -0700 (PDT) Received: from mail-bw0-f174.google.com (mail-bw0-f174.google.com [209.85.218.174]) by core3.amsl.com (Postfix) with ESMTP id E6C4A3A6D82 for ; Fri, 8 May 2009 03:59:27 -0700 (PDT) Received: by bwz22 with SMTP id 22so1300635bwz.37 for ; Fri, 08 May 2009 04:00:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BBdu/euH4DTToWc7Ce9n9IXOVTA6nXh6S6XB/zxuQuQ=; b=DzFCBldOkPZ06gulf0fgIzGnNGqQ76ShicwvfbH9MFIdcIjkR9wULXfxlZ3NRFPIcw eEAiZv56aKhGt06+pwG2nncTk0ie2Dec03fMXab4r7UrePGD90kgnFhbebdMTSnmyOwj i1wa3fU0YcGEClShZ3e3bxvmTbCYkc38nv48A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=iUAPaxTDLVGJuOJIzk931CK9VBZ3pK3jskz+e0rWvvBSn6fB0i86MdrKJfutx0Bnex aa7DDNvdjkCOszXC4bj6EtKMEfW2WsjnXrqSzDnSotF2yiWZexq2SJHf9NsnQijt3Fsv 6d/xaagvRSFVcMuyzqciXZhQUlW1NMmbXXUSQ= MIME-Version: 1.0 Received: by 10.204.65.78 with SMTP id h14mr3518138bki.35.1241780452861; Fri, 08 May 2009 04:00:52 -0700 (PDT) In-Reply-To: <62166606-B738-41CC-A7A0-58F681EFA6DA@voxeo.com> References: <8681d1580905060026l3763d4e1g40f42e8299af59aa@mail.gmail.com> <62166606-B738-41CC-A7A0-58F681EFA6DA@voxeo.com> Date: Fri, 8 May 2009 13:00:52 +0200 Message-ID: <8681d1580905080400o46a25499hfd61914858e4ec21@mail.gmail.com> From: Slawomir Testowy To: Dan Burnett Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: speechsc@ietf.org Subject: Re: [Speechsc] Ambiguous description of BARGE-IN-OCCURRED in section 8.8 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 10:59:29 -0000 2009/5/6 Dan Burnett : Hi, thanks for your answers. They helped me understand how a server should respond on BARGE-IN-OCCURRED. >> >> I couldn't find a definition of "active SPEAK request". I guess it is >> a current processed "SPEAK"? > > I agree that the current use of the word "active" is a bit confusing. =A0= It is > clearer if you understand the point of the BARGE-IN-OCCURRED event. =A0Wh= en an > ASR engine detects speech, if a prompt (audio) is being played the client > usually wants to cancel the audio being played. =A0The kill-on-barge-in > parameter and BARGE-IN-OCCURRED event allow for this. =A0Since the audio = is > interrupted (but did not stop due to a failure in the synthesis resource)= , > it has a normal termination, meaning that there is a SPEAK-COMPLETE > generated for this bit of audio. =A0Anything queued up after it (PENDING)= , > however, is removed from the queue since the occurrence of speech during = a > prompt usually will cause a change in the dialog direction that can > invalidate all queued prompts. =A0The reason no SPEAK-COMPLETE is sent fo= r > these removed PENDING requests is to distinguish them from the case where= a > failure occurs during the playout of the current audio. =A0In that case (= see > Section 8.6, next-to-last paragraph), each PENDING request stops with a > SPEAK-COMPLETE (with Completion-Cause of "cancelled"). > I don't see this paragraph in RFC4463. Was it introduced in MRCPv2? Maybe this is a little bit offtopic, but how should server implementing MRC= Pv1 behave in such case? > So, in the text above "active" means either IN-PROGRESS or PAUSED. > >> >> >>> It MUST also terminate any speech requests >>> queued behind the current active one, irrespective of whether they >>> have barge-in enabled or not. >> >> Does this statement depend on previous one? I.e. must the synthesizer >> terminate all speech >> requests queued behind the current one regardless of kill-on-barge-in >> enabled in active "SPEAK"? > > It depends on the previous statement. =A0If kill-on-barge-in is enabled f= or > the currently active SPEAK request, then all queued (PENDING) requests ar= e > terminated regardless of whether or not they have kill-on-barge-in enable= d. > Just to be sure: If kill-on-barge-in is disabled for the currently active SPEAK request, server returns SUCCESS without an active-request-id-list header as described in next-to-last paragraph in 8.8? --=20 Slawomir Testowy From slawomir.testowy@gmail.com Fri May 8 04:21:36 2009 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 0FFCD3A70F9 for ; Fri, 8 May 2009 04:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 Xx6h+y-XppF6 for ; Fri, 8 May 2009 04:21:35 -0700 (PDT) Received: from mail-bw0-f174.google.com (mail-bw0-f174.google.com [209.85.218.174]) by core3.amsl.com (Postfix) with ESMTP id 86E403A6C47 for ; Fri, 8 May 2009 04:21:31 -0700 (PDT) Received: by bwz22 with SMTP id 22so1311118bwz.37 for ; Fri, 08 May 2009 04:22:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=Gxh8nPbCSBmNzTC3pJTBjnYQjRqa45FzKRbgTWFzXSs=; b=OfXhT5LbuqXpsLZkMoMj6s+PHJH+wwBHYYEhHv5KlSRMVzHU9NUufgO8HSvUsmI1sm S8uYTeCDEKAt9le6G/y3GsOt6d0RihymwgzLu+OEwQFIxzYK9kuZLC7aZrLxp9dI9Hm9 aa7zaDrimeI8axoeRp8y+x39TVfz9lQUHpteo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=BUiTRnOBXjDRtrZycxsHnFzpy8Z01bd99e3eTDiztsaV20+rUnnFN24O/VkF9PczSb IrZz7DdzBihNuTVQsTQQlYEugBTPaITIFe1FcZkJo5qEuifvUmxkDeJUxSu4GPgZM7IY cqW45arFJmEbdU0ZavWEyHUVCss3AfuU3P6Co= MIME-Version: 1.0 Received: by 10.204.65.78 with SMTP id h14mr3537422bki.35.1241781776251; Fri, 08 May 2009 04:22:56 -0700 (PDT) Date: Fri, 8 May 2009 13:22:56 +0200 Message-ID: <8681d1580905080422i446b0aachc7f27746ad464430@mail.gmail.com> From: Slawomir Testowy To: speechsc@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Speechsc] MRCPv2 Protocol Basics - Questions 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: Fri, 08 May 2009 11:21:36 -0000 Hi, I have few more questions regarding MRCPv2. > 4.2. Managing Resource Control Channels > When the client wants to add a media processing resource to the > session, it issues a SIP re-INVITE transaction. Is it possible to allocate more than one resource of the same type during one SIP dialog? Example in 4.2 shows how to allocate synthesizer and recognizer, but does not specify if there may be e.g. more than one synthesizer. > When the client wants to de-allocate the resource from this session, > it issues a SIP re-INVITE transaction with the server. The SDP MUST > offer the control m-line with port 0. The server MUST then answer > the control m-line with a response of port 0. This de-allocates the > associated MRCPv2 identifier and resource. The server MUST NOT close > the TCP, SCTP or TLS connection if it is currently being shared among > multiple MRCP channels. When all MRCP channels that may be sharing > the connection are released and/or the associated SIP dialog is > terminated, the client or server terminates the connection. Can client open connection with the server, send SET-PARAMS request and close connection? Then open second connection, send SPEAK request and close connection without waiting for any events? > 4.4. MRCPv2 Message Transport > Multiple resource control channels between a client and > a server that belong to different SIP dialogs can share one or more > TLS, TCP or SCTP connections between them; the server and client MUST > support this mode of operation. The individual MRCPv2 messages carry > the MRCPv2 channel identifier in their Channel-Identifier header, > which MUST be used to differentiate MRCPv2 messages from different > resource channels (see Section 6.2.1 for details). Is it possible to use more than one TCP (or TLS or SCTP) connection for one control channel? Can client send messages with the same channel identifier using many connections? -- Slawomir Testowy From nik.waldron@kaz-group.com Sun May 10 19:01:38 2009 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 6ADA43A6904 for ; Sun, 10 May 2009 19:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, 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 XXTu7Sqtwj8X for ; Sun, 10 May 2009 19:01:31 -0700 (PDT) Received: from mail29.messagelabs.com (mail29.messagelabs.com [216.82.249.147]) by core3.amsl.com (Postfix) with SMTP id DE78A3A682D for ; Sun, 10 May 2009 19:01:30 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: nik.waldron@kaz-group.com X-Msg-Ref: server-4.tower-29.messagelabs.com!1242007379!40675227!1 X-StarScan-Version: 6.0.0; banners=kaz-group.com,-,- X-Originating-IP: [203.28.13.56] Received: (qmail 23471 invoked from network); 11 May 2009 02:02:59 -0000 Received: from mail02.kaz-group.com (HELO mail02.kaz-group.com) (203.28.13.56) by server-4.tower-29.messagelabs.com with SMTP; 11 May 2009 02:02:59 -0000 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 ; Mon, 11 May 2009 12:02:56 +1000 Date: Mon, 11 May 2009 12:03:40 +1000 MIME-Version: 1.0 To: dburnett@voxeo.com 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 05/11/2009 12:02:58 PM, Serialize complete at 05/11/2009 12:02:58 PM Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01C9D230.862366E0" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 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 02:01:38 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0027_01C9D230.862366E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks for your response Dan, The additional code resolves the problem (2) of noisy or otherwise 'bad' 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'm not sure if my confusion has reach beyond myself and justifies an explanatory note in the verification section. Thanks for the clarification in any case. I think that the document 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 examples often resolve confusion for readers learning a new protocol. I note that there are examples in the document, although not any training (enrolment) examples that I recall for speaker verification. I appreciate the enormous effort that goes into producing a standard protocol (everyone's a critic). I'd be happy to contribute some example conversations for Verification if such a section or document eventuates. Best regards, NIK WALDRON _____ From: dburnett@voxeo.com [mailto:dburnett@voxeo.com] Sent: Wednesday, May 06, 2009 6:29 AM To: Nik Waldron Cc: speechsc@ietf.org Subject: Re: [Speechsc] Speaker Verification - Insufficient or Noisy Speech Nik, Thanks for your email. There are three cases in what you have described: 1. speech not detected (because of SNR problem, etc.). This will return no-input-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 verification process. Note that this could happen if the speech passes the endpointer threshold but is too garbled or noisy to be of 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 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 "accepted" or "rejected" just like verification results -- the former case means there is sufficient training data and the new voiceprint is acceptable. The latter means there is sufficient training data but the new voiceprint is rejected, because for example it is 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 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 > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ This is an email 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 contain copyright and/or legally privileged information. No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive this email in error, please return to sender. Thank you. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ ------=_NextPart_000_0027_01C9D230.862366E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re:=20[Speechsc]=20Speaker=20Verification=20-=20Insufficient=20or=20= Noisy=20Speech Thanks=20for=20your=20response=20Dan,=

 

The=20additional=20code=20resolves=20= the=20problem=20(2) of=20noisy=20or=20otherwise=20‘bad’=20input,=20and=20(3)=20cla= rifies=20how=20to=20specify that=20additional=20data=20is=20needed=20for=20training.=

 

I=20had=20not=20realised=20that=20res= ult=20structure was=20intended=20be=20used=20in=20the=20case=20of=20enrolments=20as=20well= =20as=20verifications.  I’m=20not=20sure=20if=20my=20confusion=20has=20reach=20beyond=20myse= lf=20and=20justifies=20an explanatory=20note=20in=20the=20verification=20section. =20Thanks=20f= or=20the clarification=20in=20any=20case. =20

 

I=20think=20that=20the=20document=20w= ould=20benefit=20from an=20appendix=20(or=20a=20separate=20document=20as=20is=20the=20case=20for= =20SDP)=20which=20has=20examples=20of all=20of=20the=20major=20use=20cases. =20In=20my=20opinion=20examples= =20often=20resolve confusion=20for=20readers=20learning=20a=20new=20protocol. =20I=20not= e=20that=20there=20are examples=20in=20the=20document,=20although=20not=20any=20training=20(enrol= ment)=20examples=20that=20I recall=20for=20speaker=20verification.

 

I=20appreciate=20the=20enormous=20eff= ort=20that=20goes into=20producing=20a=20standard=20protocol=20(everyone’s=20a=20criti= c). =20I’d be=20happy=20to=20contribute=20some=20example=20conversations=20for=20Veri= fication=20if=20such=20a section=20or=20document=20eventuates.

 

Best=20regards,

 

 

 

NIK=20WALDRON

 

From: dburnett@voxeo.com=20[mailto:dburnett@voxeo.com]=20
Sent:=20Wednesday,=20May=20= 06,=202009=206:29 AM
To:=20Nik=20Waldron
Cc:=20speechsc@ietf.org
Subject:=20Re:=20[Speechs= c]=20Speaker Verification=20-=20Insufficient=20or=20Noisy=20Speech

 

Nik,

Thanks=20for=20your=20email.

There=20are=20three=20cases=20in=20what=20you=20have=20described:

1.=20speech=20not=20detected=20(because=20of=20SNR=20problem,=20etc.).&nbs= p;=20This=20will 
return=20no-input-timeout,=20just=20as=20it=20would=20for=20a=20speech=20r= ecognizer.

2.=20speech=20detected,=20neither=20too=20early=20(speech-too-early)=20nor= =20too=20much 
(too-much-speech-timeout),=20but=20still=20unusable=20by=20the=20training=20= or 
verification=20process. =20Note=20that=20this=20could=20happen=20if=20= the=20speech 
passes=20the=20endpointer=20threshold=20but=20is=20too=20garbled=20or=20no= isy=20to=20be=20of 
use=20to=20the=20verification=20engine.
This=20case=20is=20not=20handled=20in=20MRCP=20today. =20I=20have=20a= dded=20error=20code 011, 
"speech-not-usable",=20for=20this=20case.

3.=20additional=20turns=20are=20needed: =20the=20<decision>=20r= esult=20element=20can be 
used=20for=20this. =20"undecided"=20was=20the=20value=20we=20= chose=20to=20represent the 
case=20where=20the=20engine=20did=20not=20yet=20have=20enough=20data=20to=20= decide=20on=20a 
verification=20or=20training=20result. =20Note=20that=20training=20de= cisions=20can 
also=20be=20"accepted"=20or=20"rejected"=20just=20like= =20verification results=20--=20the 
former=20case=20means=20there=20is=20sufficient=20training=20data=20and=20= the=20new 
voiceprint=20is=20acceptable. =20The=20latter=20means=20there=20is=20= sufficient 
training=20data=20but=20the=20new=20voiceprint=20is=20rejected,=20because=20= for=20example 
it=20is=20too=20close=20to=20an=20existing=20voiceprint.

--=20dan

On=20Jan=2011,=202009,=20at=207:06=20PM,=20Nik=20Waldron=20wrote:

>=20I=20sent=20an=20email=20previously=20requesting=20information=20on=20= how=20a=20speaker
>=20verification
>=20system=20implementing=20MRCPv2=20should=20cope=20in=20the=20situati= on,=20where=20there 
>=20was
>=20insufficient=20or=20poor=20quality=20speech=20arriving=20on=20the=20= RTP=20audio 
>=20stream. =20It
>=20seemed
>=20to=20me=20that=20was=20an=20area=20of=20some=20deficiency=20in=20th= e=20specification. =20I
>=20received=20no
>=20feedback=20other=20than=20one=20response=20saying=20that=20to=20his= =20knowledge=20there 
>=20were
>=20no
>=20other=20implementers=20for=20Speaker=20Verification.
>
>=20Below=20I=20outline=20the=20MRCPv2=20exchanges=20for=20a=20training= =20operation:
>
>  =20C->S: =20MRCP/2.0=20207=20START-SESSION=2031416= 1
>          Channel-Identifier:32AECB23433801@speakverify
>         =20Repository-UR= I:http://www.example.com/vo= iceprintdbase/
>         =20Voiceprint-Mo= de:train
>          Voiceprint-Identifier:johnsmith.voiceprint
>
>  =20S->C: =20MRCP/2.0=2082=20314161=20200=20COMPLET= E
>          Channel-Identifier:32AECB23433801@speakverify
>
>  =20C->S: =20MRCP/2.0=2076=20VERIFY=20314162
>          Channel-Identifier:32AECB23433801@speakverify
>
>  =20S->C: =20MRCP/2.0=2085=20314162=20200=20IN-PROG= RESS
>          Channel-Identifier:32AECB23433801@speakverify
>
>=20The=20end-point=20detector=20show=20insufficient=20data=20(which=20= is=20buffered), 
>=20or=20bad
>=20signal=20quality=20(bad=20SNR=20for=20example). =20Note=20that= =20no START-OF-INPUT 
>=20has=20NOT
>
>=20been=20sent=20although=20speech=20has=20begun.
>
>  =20S->C: =20MRCP/2.0=20140=20VERIFICATION-COMPLETE= =20314162 COMPLETE
>          Channel-Identifier:32AECB23433801@speakverify
>         =20Completion-Ca= use:002 no-input-timeout
>
>=20This=20is=20undesirable=20from=20my=20perspective=20since=20it=20gi= ves=20the 
>=20impression=20to
>=20the
>=20client=20that=20no=20data=20has=20been=20received=20(untrue=20in=20= the=20insufficient=20data
>=20case),=20and
>=20provides=20no=20distinction=20between=20this=20and=20the=20"ba= d=20data" case. =20This
>=20information
>=20might=20be=20of=20utility=20to=20a=20call-flow=20designer=20in=20an= =20IVR=20system.
>
>=20I=20also=20note=20that=20in=20the=20case=20of=20text-independent=20= verifiers=20several 
>=20turns
>=20worth=20of
>=20data=20may=20be=20required=20for=20a=20verification. =20Severa= l=20rounds=20of=20"no input"
>=20timeouts
>=20would=20surely=20be=20confusing=20to=20the=20client,=20yet=20this=20= class=20of=20verifiers 
>=20may
>=20be=20unable
>=20to=20generate=20and=20nlsml+xml=20response=20on=20the=20nth=20dialo= g=20turn.
>
>=20The=20enrolment=20might=20then=20continue:
>
>  =20C->S: =20MRCP/2.0=2076=20VERIFY=20314163
>          Channel-Identifier:32AECB23433801@speakverify
>
>  =20S->C: =20MRCP/2.0=2085=20314163=20200=20IN-PROG= RESS
>          Channel-Identifier:32AECB23433801@speakverify
>
>  =20S->C: =20MRCP/2.0=2096=20START-OF-INPUT=2031416= 3=20IN-PROGRESS
>          Channel-Identifier:32AECB23433801@speakverify
>
>  =20S->C: =20MRCP/2.0=20131=20VERIFICATION-COMPLETE= =20314163 COMPLETE
>          Channel-Identifier:32AECB23433801@speakverify
>         =20Completion-Ca= use:000 success
>
>  =20C->S: =20MRCP/2.0=2076=20VERIFY=20314164
>          Channel-Identifier:32AECB23433801@speakverify
>
>  =20S->C: =20MRCP/2.0=2085=20314164=20200=20IN-PROG= RESS
>          Channel-Identifier:32AECB23433801@speakverify
>
>  =20S->C: =20MRCP/2.0=2096=20START-OF-INPUT=2031416= 4=20IN-PROGRESS
>          Channel-Identifier:32AECB23433801@speakverify
>
>  =20S->C: =20MRCP/2.0=20131=20VERIFICATION-COMPLETE= =20314164 COMPLETE
>          Channel-Identifier:32AECB23433801@speakverify
>         =20Completion-Ca= use:000 success
>
>  =20C->S: =20MRCP/2.0=2081=20END-SESSION=20314174 >          Channel-Identifier:32AECB23433801@speakverify
>
>  =20S->C: =20MRCP/2.0=2082=20314174=20200=20COMPLET= E
>         =20Channel-Ident= ifier:32AECB23433801@speakverify
>
>=20Since=20I=20received=20no=20responses=20(perhaps=20due=20to=20being= =20close=20to=20the 
>=20holiday
>=20season),
>=20I=20will=20venture=20a=20proposal=20for=20extending=20the=20RFC=20t= o=20include=20the=20bad 
>=20signal
>=20cases
>=20(+=20indicates=20an=20addition,=20*=20a=20modification)
>
>  =20+------------+--------------------------
>=20+---------------------------+
>  =20|=20Cause-Code=20| Cause-Name          &nbs= p;    | 
> Description          &nb= sp;    |
>  =20+------------+--------------------------
>=20+---------------------------+
>  =20|=20000       =20|=20= success           &= nbsp;      |=20VERIFY 
> or            =      |
>   |            |            &= nbsp;           &nb= sp; |=20VERIFY-FROM-
>=20BUFFER       =20|
>   |            |            &= nbsp;           &nb= sp; |=20request 
>=20completed        =20|
>   |            |            &= nbsp;           &nb= sp; |=20successfully. =20The 
>=20verify=20|
>   |            |            &= nbsp;           &nb= sp; |=20decision=20can 
>=20be          =20|<= br> >   |            |            &= nbsp;           &nb= sp; |=20"accepted", 
>=20"rejected",  =20|
>   |            |            &= nbsp;           &nb= sp; |=20or 
>=20"undecided".       &nb= sp;   |
>  =20|=20001       =20| error           &nb= sp;        |=20VERIFY 
> or            =      |
>   |            |            &= nbsp;           &nb= sp; |=20VERIFY-FROM-
>=20BUFFER       =20|
>   |            |            &= nbsp;           &nb= sp; |=20request 
>=20terminated       =20|
>   |           =20|&nb= sp;            = ;             |=20prematurely=20due=20to 
>=20a     =20|
>   |            |            &= nbsp;           &nb= sp; |=20verification=20resource 
>=20or =20|
>   |            |            &= nbsp;           &nb= sp; |=20system 
> error.           &n= bsp; |
>  =20|=20002       =20| no-input-timeout        =20|=20VER= IFY request 
>=20completed =20|
>   |            |            &= nbsp;           &nb= sp; |=20with=20no=20result=20due=20to 
>=20a  =20|
>   |            |            &= nbsp;           &nb= sp; |=20no-input-
>=20timeout.        =20|
>  =20|=20003       =20| too-much-speech-timeout =20|=20VERIFY=20request 
>=20completed =20|
>   |            |            &= nbsp;           &nb= sp; |=20result=20due=20to=20too 
>=20much   =20|
>   |            |            &= nbsp;           &nb= sp; | 
> speech.           &= nbsp;       |
>  =20|=20004       =20| speech-too-early        =20|=20VER= IFY request 
>=20completed =20|
>   |            |            &= nbsp;           &nb= sp; |=20with=20no=20result=20due 
>=20to    =20|
>   |            |            &= nbsp;           &nb= sp; |=20spoke=20too 
>=20soon.          =20= |
>=20+=20|=20005       =20| insufficient-speech     =20|=20VERIFY 
> or            =      |
>=20+=20|          &n= bsp; |            &= nbsp;           &nb= sp; |=20VERIFY-FROM-
>=20BUFFER       =20|
>=20+=20|          &n= bsp; |            &= nbsp;           &nb= sp; |=20request 
>=20completed        =20|
>=20+=20|          &n= bsp; |            &= nbsp;           &nb= sp; |=20successfully=20but 
>=20had     =20|
>=20+=20|          &n= bsp; |            &= nbsp;           &nb= sp; |=20insufficient=20speech 
>=20to   =20|
>=20+=20|          &n= bsp; |            &= nbsp;           &nb= sp; |=20complete. =20More 
>=20speech   =20|
>=20+=20|          &n= bsp; |            &= nbsp;           &nb= sp; |=20will=20complete=20the 
>=20current=20|
>=20+=20|          &n= bsp; |            &= nbsp;           &nb= sp; |=20incremental 
>=20operation    =20|
>=20+=20|=20006       =20| bad-speech          &nbs= p;    |=20VERIFY 
> or            =      |
>=20+=20|          &n= bsp; |            &= nbsp;           &nb= sp; |=20VERIFY-FROM-
>=20BUFFER       =20|
>=20+=20|          &n= bsp; |            &= nbsp;           &nb= sp; |=20request 
>=20completed        =20|
>=20+=20|          &n= bsp; |            &= nbsp;           &nb= sp; |=20unsuccessfully, 
>=20the      =20|
>=20+=20|          &n= bsp; |            &= nbsp;           &nb= sp; |=20speech=20quality=20was 
>=20too   =20|
>=20+=20|          &n= bsp; |            &= nbsp;           &nb= sp; | 
> poor           &nbs= p;          |
>=20* =20|=20007       =20| buffer-empty          &n= bsp;  |=20VERIFY-FROM-
>=20BUFFER       =20|
>   |            |            &= nbsp;           &nb= sp; |=20request=20completed=20with 
>=20no=20|
>   |            |            &= nbsp;           &nb= sp; |=20result=20due=20to 
>=20empty      =20|
>   |            |            &= nbsp;           &nb= sp; | 
> buffer.           &= nbsp;       |
>=20* =20|=20008       =20| out-of-sequence         =20| Verification 
>=20operation   =20|
>   |            |            &= nbsp;           &nb= sp; |=20failed=20due 
>=20to           = ;  |
>   |            |            &= nbsp;           &nb= sp; |=20out-of-sequence 
>=20method   =20|
>   |            |            &= nbsp;           &nb= sp; |=20invocations. =20For 
>=20example=20|
>   |            |            &= nbsp;           &nb= sp; |=20calling=20VERIFY 
>=20before    =20|
>   |            |            &= nbsp;           &nb= sp; |=20QUERY-
>=20VOICEPRINT.        =20|
= >=20* =20|=20009       =20| repository-uri-failure  =20|=20Failure 
>=20accessing        =20|
>   |            |            &= nbsp;           &nb= sp; |=20Repository 
>=20URI.          =20= |
>=20* =20|=20010       =20| repository-uri-missing  =20|=20Repository-uri=20is 
>=20not    =20|
>   |            |            &= nbsp;           &nb= sp; | 
> specified.          &nbs= p;     |
>=20* =20|=20011       =20| voiceprint-id-missing   =20|=20Voiceprint-
>=20identification=20|
>   |            |            &= nbsp;           &nb= sp; |=20is=20not 
>=20specified.        =20|
>=20* =20|=20012       =20| voiceprint-id-not-exist =20|=20Voiceprint-
>=20identification=20|
>   |            |            &= nbsp;           &nb= sp; |=20does=20not=20exist=20in 
>=20the    =20|
>   |            |            &= nbsp;           &nb= sp; |=20voiceprint 
>=20repository.   =20|
>  =20+------------+--------------------------
>=20+---------------------------+
>
>=20Alternatively=20the=20new=20entries=20could=20be=20appended=20for compatibility.  
>=20The
>=20only
>=20disadvantage=20to=20doing=20so=20would=20be=20that=20entries=20woul= d=20not=20be=20grouped 
>=20in=20the
>=20table=20by=20category.
>
>=20I'll=20happily=20accept=20any=20corrections=20to=20my=20understandi= ng,=20incase=20I=20have
>=20misread
>=20the=20spec,=20or=20feedback=20on=20my=20suggestions.
>
>
>
>
>=20NIK=20WALDRON
>
>=20_______________________________________________
>=20Speechsc=20mailing=20list
>=20Speechsc@ietf.org
>=20https:= //www.ietf.org/mailman/listinfo/speechsc
>=20Supplemental=20web=20site:
>=20&lt;http://www.messagelabs.com/email
______________________________________________________________________


This=20is=20an=20email=20from=20Fujitsu=20Australia=20Limited,=20ABN=2019=20= 001=20011=20427.=20It=20is=20confidential=20to=20the=20ordinary=20user=20o= f=20the=20email=20address=20to=20which=20it=20was=20addressed=20and=20may=20= contain=20copyright=20and/or=20legally=20privileged=20information.=20No=20= one=20else=20may=20read,=20print,=20store,=20copy=20or=20forward=20all=20o= r=20any=20of=20it=20or=20its=20attachments.=20If=20you=20receive=20this=20= email=20in=20error,=20please=20return=20to=20sender.=20Thank=20you.
______________________________________________________________________
= This=20email=20has=20been=20scanned=20by=20the=20MessageLabs=20Email=20Sec= urity=20System.
For=20more=20information=20please=20visit=20http://www.messagelabs.com/ema= il=20
______________________________________________________________________
= ------=_NextPart_000_0027_01C9D230.862366E0-- From eburger@standardstrack.com Mon May 11 06:58:24 2009 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 4666B28C11C for ; Mon, 11 May 2009 06:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, J_CHICKENPOX_53=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 nQRq7zToP66u for ; Mon, 11 May 2009 06:58:22 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 763FB3A688B for ; Mon, 11 May 2009 06:58:22 -0700 (PDT) Received: from c-75-68-112-157.hsd1.nh.comcast.net ([75.68.112.157] helo=[192.168.45.106]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1M3W2o-00012J-7e; Mon, 11 May 2009 06:59:50 -0700 Message-Id: <6F3109CD-FF17-43A2-A4BE-71A6A488D22D@standardstrack.com> From: Eric Burger To: Nik Waldron In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-14--397300717; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 11 May 2009 09:59:47 -0400 References: X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: 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 13:58:24 -0000 --Apple-Mail-14--397300717 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable 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, > > > > The additional code resolves the problem (2) of noisy or otherwise =20 > =91bad=92 input, and (3) clarifies how to specify that additional data = =20 > is needed for training. > > > > I had not realised that result structure was intended be used in the =20= > case of enrolments as well as verifications. I=92m not sure if my =20 > confusion has reach beyond myself and justifies an explanatory note =20= > in the verification section. Thanks for the clarification in any =20 > case. > > > > I think that the document would benefit from an appendix (or a =20 > separate document as is the case for SDP) which has examples of all =20= > of the major use cases. In my opinion examples often resolve =20 > confusion for readers learning a new protocol. I note that there =20 > are examples in the document, although not any training (enrolment) =20= > examples that I recall for speaker verification. > > > > I appreciate the enormous effort that goes into producing a standard =20= > protocol (everyone=92s a critic). I=92d be happy to contribute some =20= > example conversations for Verification if such a section or document =20= > eventuates. > > > > Best regards, > > > > > > > > NIK WALDRON > > > > From: dburnett@voxeo.com [mailto:dburnett@voxeo.com] > Sent: Wednesday, May 06, 2009 6:29 AM > To: Nik Waldron > Cc: speechsc@ietf.org > Subject: Re: [Speechsc] Speaker Verification - Insufficient or Noisy =20= > Speech > > > > Nik, > > Thanks for your email. > > There are three cases in what you have described: > > 1. speech not detected (because of SNR problem, etc.). This will > return no-input-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 > verification process. Note that this could happen if the speech > passes the endpointer threshold but is too garbled or noisy to be of > 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 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 "accepted" or "rejected" just like verification results -- the > former case means there is sufficient training data and the new > voiceprint is acceptable. The latter means there is sufficient > training data but the new voiceprint is rejected, because for example > it is 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 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 =20= > 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 =20 > 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 =20= > 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> > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > > This is an email from Fujitsu Australia Limited, ABN 19 001 011 427. =20= > It is confidential to the ordinary user of the email address to =20 > which it was addressed and may contain copyright and/or legally =20 > privileged information. No one else may read, print, store, copy or =20= > forward all or any of it or its attachments. If you receive this =20 > email in error, please return to sender. Thank you. > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www.ietf.org/mailman/listinfo/speechsc > Supplemental web site: > <http://www.standardstrack.com/ietf/speechsc> --Apple-Mail-14--397300717 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4 loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0 pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z 8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2 KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8 MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA1MTExMzU5NDhaMCMGCSqGSIb3 DQEJBDEWBBSoRafxu2l1ftwR9zcb0Nviy4alADCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQBprXa5uoV5pICVGyrqD9ZN6wuPpKh/vCTMr2GycxzG5Q39 vbmbHfwhM8FrVNSrfTCRecX4j+gBE1J0MitOXj0wWMS9LzV9UuBO8dYwUBn+rXet1y1H90qtZOAz 2RWFVQCfJhkK8T+yvdnn0w+/zdg5u0xYXeZDAyAlYp0CmbNH1A3PkX3OemVhMZbL+4zEV0ksmgDD 2oU80UH7KobH0opbnhycVfzghrhNUxrP8U31mRg1PjPKwjNVEexnJD0AO9CaFBL24v48oFQfUTT6 k8A1mkHP9cpSIReFKRBD4B/h/EVa7KCzg+2hPJcvpgnx/3hYHiNK6Fq3kswGMw8OJtLyAAAAAAAA --Apple-Mail-14--397300717-- From achaloyan@yahoo.com Mon May 11 08:13:16 2009 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-- From eburger@standardstrack.com Mon May 11 09:19:49 2009 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 263E33A6A99 for ; Mon, 11 May 2009 09:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_53=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 pnsqBMm9uyyg for ; Mon, 11 May 2009 09:19:47 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id ABC703A68B4 for ; Mon, 11 May 2009 09:19:47 -0700 (PDT) Received: from c-75-68-112-157.hsd1.nh.comcast.net ([75.68.112.157] helo=[192.168.45.106]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1M3YFd-0006ur-Ro; Mon, 11 May 2009 09:21:14 -0700 Message-Id: From: Eric Burger To: Arsen Chaloyan In-Reply-To: <36904.3443.qm@web111304.mail.gq1.yahoo.com> Content-Type: multipart/signed; boundary=Apple-Mail-19--388815639; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 11 May 2009 12:21:12 -0400 References: <6F3109CD-FF17-43A2-A4BE-71A6A488D22D@standardstrack.com> <36904.3443.qm@web111304.mail.gq1.yahoo.com> X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: 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 16:19:49 -0000 --Apple-Mail-19--388815639 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable That would be awesome. The reason I am pushing back on expanding the scope of the base =20 specification is that we can always make it better. However, we are =20 already three years late, and unless something is glaringly incorrect =20= or will harm the Internet, and given there are so many implementations =20= of -16 out there, we should just get this published as an RFC and we =20 can work on examples, extensions, and clarifications in separate =20 documents. On May 11, 2009, at 11:14 AM, Arsen Chaloyan wrote: > Book is definitely good. > However SDP o/a examples (RFC4317) like online resource would be =20 > indeed helpful. > It's not matter of just examples, but it may also cover error cases. > Reading the latest draft, it's still not always obvious what error =20 > response should be sent in some particular cases. Clearly it's not =20 > possible to cover all the cases in foundation specification. > I'll be happy to create such resource in the scope (web) of open =20 > source MRCP project I maintain, if it makes sense. > > Regards, > Arsen Chaloyan > www.unimrcp.org > > From: Eric Burger > To: Nik Waldron > Cc: speechsc@ietf.org > Sent: Monday, May 11, 2009 6:59:47 PM > Subject: Re: [Speechsc] Speaker Verification - Insufficient or Noisy =20= > Speech > > 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, > > > > > > > > The additional code resolves the problem (2) of noisy or otherwise =20= > =91bad=92 input, and (3) clarifies how to specify that additional data = =20 > is needed for training. > > > > > > > > I had not realised that result structure was intended be used in =20 > the case of enrolments as well as verifications. I=92m not sure if my = =20 > confusion has reach beyond myself and justifies an explanatory note =20= > in the verification section. Thanks for the clarification in any =20 > case. > > > > > > > > I think that the document would benefit from an appendix (or a =20 > separate document as is the case for SDP) which has examples of all =20= > of the major use cases. In my opinion examples often resolve =20 > confusion for readers learning a new protocol. I note that there =20 > are examples in the document, although not any training (enrolment) =20= > examples that I recall for speaker verification. > > > > > > > > I appreciate the enormous effort that goes into producing a =20 > standard protocol (everyone=92s a critic). I=92d be happy to = contribute =20 > some example conversations for Verification if such a section or =20 > document eventuates. > > > > > > > > Best regards, > > > > > > > > > > > > > > > > NIK WALDRON > > > > > > > > From: dburnett@voxeo.com [mailto:dburnett@voxeo.com] > > Sent: Wednesday, May 06, 2009 6:29 AM > > To: Nik Waldron > > Cc: speechsc@ietf.org > > Subject: Re: [Speechsc] Speaker Verification - Insufficient or =20 > Noisy Speech > > > > > > > > Nik, > > > > Thanks for your email. > > > > There are three cases in what you have described: > > > > 1. speech not detected (because of SNR problem, etc.). This will > > return no-input-timeout, just as it would for a speech recognizer. > > > > 2. speech detected, neither too early (speech-too-early) nor too =20 > much > > (too-much-speech-timeout), but still unusable by the training or > > verification process. Note that this could happen if the speech > > passes the endpointer threshold but is too garbled or noisy to be of > > use to the verification engine. > > This case is not handled in MRCP today. I have added error code =20 > 011, > > "speech-not-usable", for this case. > > > > 3. additional turns are needed: the result element can =20= > 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 "accepted" or "rejected" just like verification results -- =20= > the > > former case means there is sufficient training data and the new > > voiceprint is acceptable. The latter means there is sufficient > > training data but the new voiceprint is rejected, because for =20 > example > > it is 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 the situation, where =20 > 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 =20 > 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 =20 > insufficient data > > > case), and > > > provides no distinction between this and the "bad data" case. =20 > 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 =20= > input" > > > timeouts > > > would surely be confusing to the client, yet this class of =20 > 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 =20 > grouped > > > in the > > > table by category. > > > > > > I'll happily accept any corrections to my understanding, incase =20= > 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: > > > > > > > > > =20 > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email Security =20 > System. > > For more information please visit http://www.messagelabs.com/email > > =20 > ______________________________________________________________________ > > > > > > This is an email from Fujitsu Australia Limited, ABN 19 001 011 =20 > 427. It is confidential to the ordinary user of the email address to =20= > which it was addressed and may contain copyright and/or legally =20 > privileged information. No one else may read, print, store, copy or =20= > forward all or any of it or its attachments. If you receive this =20 > email in error, please return to sender. Thank you. > > =20 > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email Security =20 > System. > > For more information please visit http://www.messagelabs.com/email > > =20 > ______________________________________________________________________ > > _______________________________________________ > > Speechsc mailing list > > Speechsc@ietf.org > > https://www.ietf.org/mailman/listinfo/speechsc > > Supplemental web site: > > > --Apple-Mail-19--388815639 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4 loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0 pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z 8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2 KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8 MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA1MTExNjIxMTNaMCMGCSqGSIb3 DQEJBDEWBBS9UFyqFBXKq0o2kPytbulS4XrKjjCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQClbtrdutbnliGLosHS1YTQQt0Og3P1L4f7Yz3R4Q7TQaOq wgMzVwPNCjH/1Nf0SB0b85Ma0vvqIaw3+qINd2WxLwJzdQmxHw0yELb+zNfRj9lgXw33jdKCuvH3 ol7mzxfhDbAlfC4zjfe/lTLr7EeEAvM6lUmrLWB7h6ZR++Rh7f0hNlK0nKKxPpl202hoVVIaqiTc lTat6Ey2QjzSXTlQJ/WIkhYTVvYkpJMHQQ61blR0m2jwlrQgmPuVEK/uN0BGClmUkZhYOHa86PBj EZX/LRtQukWlYSrUtFts9zjc16XJ705wuvHnTmJtNZySnrNmOG0xLc4lWTDeDeWq/PztAAAAAAAA --Apple-Mail-19--388815639-- From achaloyan@yahoo.com Mon May 18 04:55:16 2009 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 B5FF028C2B8 for ; Mon, 18 May 2009 04:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.202 X-Spam-Level: * X-Spam-Status: No, score=1.202 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=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 tYfjleoOPNol for ; Mon, 18 May 2009 04:55:15 -0700 (PDT) Received: from n7.bullet.re3.yahoo.com (n7.bullet.re3.yahoo.com [68.142.237.92]) by core3.amsl.com (Postfix) with SMTP id 92B9E28C29E for ; Mon, 18 May 2009 04:55:15 -0700 (PDT) Received: from [68.142.237.87] by n7.bullet.re3.yahoo.com with NNFMP; 18 May 2009 11:56:49 -0000 Received: from [67.195.9.83] by t3.bullet.re3.yahoo.com with NNFMP; 18 May 2009 11:56:49 -0000 Received: from [67.195.9.108] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 18 May 2009 11:56:49 -0000 Received: from [127.0.0.1] by omp112.mail.gq1.yahoo.com with NNFMP; 18 May 2009 11:56:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 245500.30206.bm@omp112.mail.gq1.yahoo.com Received: (qmail 6671 invoked by uid 60001); 18 May 2009 11:56:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1242647809; bh=CuDG5+wUZ0SPMfkTGAbP2y+PYf4S9AZnIKu2z08xjlM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=xP1Z40qGtzuk00WGu8aD0W4eKAJSqfs2JKZcmY2dZNv/I6FXNGK2CQfq+9frYLF4EekZqe9J54xvjQgCNvg9CE0qWKyhwcHiJl6N3Q8dvMIItcWhqEijyERYOEE/bnW1wR1eWPlf04IeAtQ8BmElTG6wW6zKKGfT0IH/+YYjvLU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=oClf8DIcbzlZJjepQIuybk3eEnpoJXHzAe0V6Z5clupI9EaJAjXtguCA2XAvUjKh+0USLi30Eo57R3Tp0V1LL5q9dJ5QIMm4inXZmv/xlUsnbS4bTsB3JI+X8+6vMLOBbl0RWEtA0shdiVztvOqYolITbKUOIqIHk+Kf0XAOZsU=; Message-ID: <149563.6667.qm@web111301.mail.gq1.yahoo.com> X-YMail-OSG: vNuCpGwVM1l.FVsGGqTvsaFgxrGFL0YzUIW2DfN3_ylvV5jEcY_PDUqtaJ8JcWiqNHOSV5FX_e2Rs2KNbgdrm3yfohjiw18PVVREHgXALHF6RG5FrduG01P27ttjsFaDdnHJbIKJpMDo93kgCYG3V_T8adfAeN.zMLjByGBhf9kyglTZclRd_1o7CHMxn3rV6kZQEvwHopn64AkL6q9ZJ.lafcIKCJiP.WMjOgfj2sVU6Jhquws49942KvBm1H5KfaLuiHNV7WyR4dOlYvO.TIUvwG6vr9XGb30uwQsbKGWZy0HW_.FA4BRKcJq.mt3Mb5KP1Hy25juUD5Y5w30eX9cLvzlmWvvdsci8J9R.QZ34WSytBGKKJ_s- Received: from [91.198.247.201] by web111301.mail.gq1.yahoo.com via HTTP; Mon, 18 May 2009 04:56:48 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 Date: Mon, 18 May 2009 04:56:48 -0700 (PDT) From: Arsen Chaloyan To: speechsc@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-480602179-1242647808=:6667" Subject: [Speechsc] Small mistake in the message flow (14.1) 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, 18 May 2009 11:55:16 -0000 --0-480602179-1242647808=:6667 Content-Type: text/plain; charset=us-ascii 14.1. Message Flow Please pay attention to the second offer, where the client requests the server to create synthesizer resource control channel m=audio 49170 RTP/AVP 0 96 a=rtpmap:0 pcmu/8000 a=recvonly a=mid:1 The offer includes two RTP payload types: 0 96. 96 is in the range of dynamic payload types, therefore its description must be present in rtpmap, but it's missing. Most probably 96 should be just removed from this offer. It makes more sense in case of recognizer resource, where 96 is used for telephone-events. Also one small suggestion: Add normative reference to RFC3551, where RTP profile is defined (codecs, payload types, dynamic range, e.t.c) Regards, Arsen Chaloyan www.unimrcp.org --0-480602179-1242647808=:6667 Content-Type: text/html; charset=us-ascii
14.1. Message Flow

Please pay attention to the second offer, where the client requests the server to create synthesizer resource control channel
          m=audio 49170 RTP/AVP 0 96
          a=rtpmap:0 pcmu/8000
          a=recvonly
          a=mid:1
The offer includes two RTP payload types: 0 96.
96 is in the range of dynamic payload types, therefore its description must be present in rtpmap, but it's missing. Most probably 96 should be just removed from this offer. It makes more sense in case of recognizer resource, where 96 is used for telephone-events.

Also one small suggestion:
Add normative reference to RFC3551, where RTP profile is defined (codecs, payload types, dynamic range, e.t.c)

Regards,
Arsen Chaloyan
www.unimrcp.org
--0-480602179-1242647808=:6667--