Subject: RE: [Speechsc] List of clarification questions regarding verification

From: "Daniel Burnett" <[email-masked]>
Date: Thu, 29 Apr 2004 15:02:55 -0700

Ran,

Here are some thoughts on some of your other comments:

6) Now that VER-STOP can be used in less of an emergency (abort) situation, it should be stated explicitly that VER-STOP does not automatically perform a rollback. In other words, the processing that has already happened for this utterance will affect the cumulative scores unless explicitly rolled back.

7) This is actually intended to start the no-input timer exactly like the similar method in the Recognizer resource.  Although one might question the usefulness of doing verification on utterances that were barge-ins over a prompt, several engines (including ours) can do this, so why not?
Note that the client would only call this method if the caller had barged in.  For consistency, we should add a verification-start-timers header field (with a default value of true) on the VERIFY method call that begins the verification timers in the same way that recognizer-start-timers does for the recognizer.

8) No. It would be adapted. You can always call VER-DELETE-VOICEPRINT if you need to.

Come to think of it, it might be cleaner to require a single session to be only training or only verification/identification (i.e., the verification-mode header should be moved to be only on the VER-START-SESSION method).  Then VER-DELETE-VOICEPRINT could be restricted to only be callable outside of a session.  This would simplify the semantics since we wouldn't have to specify what would have happened if a client deleted a voiceprint during a session that was actively modifying the voiceprint.

If we make these changes to verification-mode and VER-DELETE-VOICEPRINT, there should probably be a state machine diagram in the document to easily explain all of this.

9) Yes, since training is initiated by a call to VERIFY.  There should probably be an example of this.

-- dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Ran Zilca
Sent: Monday, April 05, 2004 11:30 AM
To: IETF SPEECHSC (E-mail)
Subject: [Speechsc] List of clarification questions regarding
verification

Hello,

Please find attached document with the list of clarification questions.

Best regards,

Ran Zilca
Conversational Biometrics
IBM T. J. Watson Research Center
1101 Kitchawan Rd.
Yorktown Heights, NY 10598

http://www.research.ibm.com/CBG

Voice:      (914) 945-3013
Fax:  (914) 945-4490

(See attached file: Calrification quetions on MRCPv1 extension for speaker
verification.doc)

_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

From: Ran Zilca <[email-masked]>
Date: Fri, 30 Apr 2004 11:06:28 -0400

Dan,

6) Agreed.

7) Agreed.

8) Restricting sessions to be training or verification only and allowing
VER-DELETE-VOICEPRINT only outside is OK with me. I also agree that a state
machine will be useful to describe these possible sequences. However, in
any case I think the spec should say explicitly that voiceprints are
adapted rather than retrained unless deleted.

Thanks,

-- Ran.

"Daniel Burnett" <[email-masked]> on 04/29/2004 06:02:55 PM

To:    Ran Zilca/Watson/IBM@IBMUS, "IETF SPEECHSC (E-mail)"
       <[email-masked]>
cc:
Subject:    RE: [Speechsc] List of clarification questions regarding
       verification

Ran,

6) Now that VER-STOP can be used in less of an emergency (abort) situation,
it should be stated explicitly that VER-STOP does not automatically perform
a rollback. In other words, the processing that has already happened for
this utterance will affect the cumulative scores unless explicitly rolled
back.

7) This is actually intended to start the no-input timer exactly like the
similar method in the Recognizer resource.  Although one might question the
usefulness of doing verification on utterances that were barge-ins over a
prompt, several engines (including ours) can do this, so why not?
Note that the client would only call this method if the caller had barged
in.  For consistency, we should add a verification-start-timers header
field (with a default value of true) on the VERIFY method call that begins
the verification timers in the same way that recognizer-start-timers does
for the recognizer.

8) No. It would be adapted. You can always call VER-DELETE-VOICEPRINT if
you need to.

Come to think of it, it might be cleaner to require a single session to be
only training or only verification/identification (i.e., the
verification-mode header should be moved to be only on the
VER-START-SESSION method).  Then VER-DELETE-VOICEPRINT could be restricted
to only be callable outside of a session.  This would simplify the
semantics since we wouldn't have to specify what would have happened if a
client deleted a voiceprint during a session that was actively modifying
the voiceprint.

If we make these changes to verification-mode and VER-DELETE-VOICEPRINT,
there should probably be a state machine diagram in the document to easily
explain all of this.

9) Yes, since training is initiated by a call to VERIFY.  There should
probably be an example of this.

-- dan

-----Original Message-----

Hello,

Best regards,

Ran Zilca

Voice:      (914) 945-3013
Fax:  (914) 945-4490