Subject: [Speechsc] Comments on draft-ietf-speechsc-reqts-00.txt

From: "Salvador Neto" <[email-masked]>
Date: Thu, 19 Sep 2002 17:26:10 -0700

A number of people in Microsoft's speech group have reviewed the
SpeechSC requirements draft in detail, and would like to raise the
following comments and questions.
 
Please forgive us if these have been discussed in the group already, as
we approach this document as relative newcomers to the group. 

And also, please make sure you include Hsiao-Wuen-Hon
([email-masked]) and Stephen Potter ([email-masked]) in your
replies, as they are still in the process of adding themselves to the
list.

Thanks,
Salvador Assumpcao Neto
Program Manager - .Net Speech group
Microsoft Corporation

Comments follow...

Section 3 (and throughout)
1. The requirements document is clearly focused on telephony gateway
scenarios. We suggest that an equally compelling scenario is mobile
multimodal scenarios where wireless mobile devices can attain ASR/SR/TTS
services via network. If the group agrees that this is an important
scenario to address, we would suggest modification or addition of the
requirements to reflect this. Specifically, we are concerned that saying
SpeechSC depends on RTP may mean that it depends on UDP. If so, we
believe that for ASR and SR services guarantee of delivery, such as
provided by TCP, may be better suited (rather than real-time
requirement), especially in the case of mobile multimodal scenarios. So
we hope SpeechSC will be open to contemplate such alternatives.

2. The term 'speaker recognition' and its acronym SR are rather
confusing, given the widespread use of SR to mean 'speech recognition'
(i.e. ASR), and the use of the word 'recognition' in both concepts. We
understand the meaning of the term to embrace both 'speaker
verification' and 'speaker identification'. We would therefore suggest a
different phrase for these capabilities: Speaker
Identification/Verification (SIV).

Section 4
3. Reference is made to VoiceXML as an example platform - we would also
suggest naming a SALT platform for the same purposes - particularly in a
mobile architecture - and we can suggest some wording here if you would
like.

Section 5.4
4. The requirement to be compatible with the IAB OPES framework is
somewhat unspecific, and appears to require more digestion of a third
party document which many readers will not undertake. Is is possible to
make this requirement more tangible without sending the reader off to
the OPES specification?

Section 5.5 
5. It's unclear whether this requirement implies that SpeechSC needs to
be aware of Load Balancing mechanisms in order to perform Load Balancing
or not. We hope this is not the case. 

Section 5.6
6. The MUST requirement to permit multiple operations on a single stream
may significantly affect SpeechSC design, but we do not believe the
scenarios which are enabled by this are sufficiently compelling to make
it a must-have. So we suggest this requirement should be a SHOULD.

Section 6
7. It is unclear what 'voicing' means in this section (in the world of
phonology it refers to a specific phenomenon of pronunciation which is
clearly not intended). Does it mean something along the lines of 'output
voice selection'? 

8. Also the term 'reading' is somewhat confusing in this section. How
about 'playback' or 'synthesis'?

9. The case of mixed TTS and audio files in the same output is not
addressed explicitly anywhere in this section. This is a common use case
(eg 'please speak after the beep <beep>', or 'here's your voice mail
<message>, what do you want to do now?'). The text seems to assume a
disjunction, but especially since SSML can carry references to remote
audio files, it may be useful to address this scenario more explicitly.

10. (paras 2, 3, 4) The subtle switch to explicit requirements on the
TTS server is confusing. Surely we should be defining requirements only
on the framework. The abilities of the components of the framework
should be called out separately either as (a) conformance issues, or (b)
assumptions on individual component capabilities. They should certainly
be in a different section. In any case, we believe the requirements in
these paragraphs should be requirements on the framework itself.

11. (para 6) The loose definitions in this paragraph render it hard to
understand. We do not understand what is actually intended by the SHOULD
and MAY capabilities here. 

12. (para 7) Again, point 10 on the TTS Server requirements. We also
believe that such capabilities are not MUSTs in either case, but rather
SHOULD for the framework (and correspondingly MAY for Server
conformance).

13. (penultimate para)
The term 'prosody' is not defined, but this is a crucial requirement on
the framework (see also point 7 on 'voicing').

Section 7
14. Again, TCP seems to be ruled out in this section. A useful
requirement may be to address 'guarantee of delivery' for ASR.

15. (para 5) The requirement to accommodate "all of the protocol
parameters" of MRCP needs to be justified. We believe it is too strong,
since it assumes that MRCP is an exact fit to SpeechSC, whereas we
believe MRCP may be over-specialized for use in VoiceXML environments.
This paragraph is also another case where crucial requirements are made
by reference to another spec; we think these should be explicit in this
document. 

16. (para 7) Again, this is a requirements on a component, and it is
unclear what it adds to the requirement on the framework in para 3.

Section 8  
17. (para 1) Again, assumption of RTP only. 

18. (para 3) It is unclear what burden this requirement places on the
framework. 

Section 9
19. It took a couple of readings to decipher that there are two very
different definitions of 'dual mode' at play here. Suggest they are
called out in advance of the rationale. 

Section 10 
20. (para 2) "Investigating' is a rather vague term for a
non-requirement. Is the intention to say that the WG will not be
'defining' DSR coding schemes?

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

---

From: "David R. Oran" <[email-masked]>
Date: Fri, 20 Sep 2002 11:23:14 -0400

Thanks for your careful and comprehensive review. This is exactly the kind 
of feedback and discussion that last call is intended for (although earlier 
would have been better :-)

Responses, comments, and requests embedded.

WG - please continue this discussion on the list - we want to see if we can 
reach closure quickly and get this to the IESG so as to not hold up the 
protocol analysis work.

> replies, as they are still in the process of adding themselves to the
Done.

> requirements to reflect this.
I, for one agree, and suspect the Wg would not have any problem with this.

> Specifically, we are concerned that saying
> SpeechSC depends on RTP may mean that it depends on UDP.
My understanding is that it does not. It is my understanding that RTP can 
be carried over TCP. The concern over broadening the coverage beyond RTP is 
that RTP is *the* media carriage standard of the IETF and we are producing 
an IETF standard here. In particular, we may wish to depend on control 
<->media protocol corellation and synchronization based on RTP timestamps 
and SSRCs. If we were to incorporate other media carriage protocols this 
might substantially complicate the protocol.

There is also the issue of barge-in and whether we can depend on the media 
protocol to have machinery that prevents or at least mitigates head-of-line 
blocking.

We could conceivably just write requirements that any media carriage 
protocol have certain characteristics, but I would be inclined to retain 
the RTP dependency for the reasons cited above.

Rapid WG and AD feedback on this particular issue is important, I think.

> If so, we
I like this suggestion (despite my proposing a different acronym in my note 
responding to anohter set of comments). If there are no objections, I will 
adopt this acronym in the next revision of the draft.

> mobile architecture - and we can suggest some wording here if you would
Please do. ASAP.

> make this requirement more tangible without sending the reader off to
Another comment asked for an example of how one might run afoul of OPES. 
Would be satisfactory?

On a more philosophical note, these requirements are meant primarily to be 
consumed by the people undertaking the analysys of existing protocols, and 
as a measure against which to evaluate any protocol the WG proposes to the 
IETF for adoption as a standard. As WG chair I would expect and indeed 
demand that at least those folks in fact read and absorb the OPES documents 
since they are relevant to the design of a SPEECHSC protocol and point out 
many pits others have fallen into.

> or not. We hope this is not the case.
Could you restate this comment, please? If speechsc itself performs load 
balancing it by definition needs to be aware of load balancing mechanisms. 
If it does not perform load balancing itself, it may still need to be aware 
that load balancing may occur, because there are known cases in which 
protocols break, or perform in a highly suboptimal way when load balanced, 
unless this was considered in the design. The intent of the requirement is 
to say that Speechsc my take into account load balancing, but not replicate 
the functions of load balancing protocols as part of its design.

We'd appreciate any attempt you could make to capture this better than the 
existing text.

> it a must-have. So we suggest this requirement should be a SHOULD.
In earlier list discussion and at the Yokohmam IETF meeting, the consensus 
was this is a MUST requirement. Let's revisit this given we have a counter 
view.

WG members, please weigh in here.

> clearly not intended). Does it mean something along the lines of 'output
In fact my understanding it was precisely the pronunciation details in 
addition to the gross aspect of selecting a particular speakers' voice 
which were intended. I could of course be wrong. WG - help us out here - 
which do you think was intended. I'll reword as needed once we have 
consensus.

> about 'playback' or 'synthesis'?
Agree, and another set of comments pointed this out. I will change to 
"playback", and note that "synthesis" is not quite right either because the 
output my be just the result of matching a work or phrase in text to a 
pre-canned audio file rather than actually doing synthesis.

> audio files, it may be useful to address this scenario more explicitly.
Agree. Could you please SUPPLY TEXT. Thanks.

> these paragraphs should be requirements on the framework itself.
Hmmm, I suppose we could do a better job here. The intent is to highlight 
how requirments on the protocol relate to things the servers are assumed to 
be doing or not doing. While separating these out lexically might 
ameliorate this problem it might cause other problems in understanding how 
the various requirements relate to one another. I could go either way on 
this. How strongly do you feel that the existing text/structure needs to 
change?

> and MAY capabilities here.
Ouch. You'll have to help me figure out what is wrong, since it's crystal 
clear to me (I know this isn't too  helpful). What we are trying to say is 
that it is pretty important (SHOULD) that the protocol be able to keep its 
control channel, and hence its basic control synchronization state, over 
longer than one session (where session is loosely corellated with a "call", 
SIP dialog, or session state of the associated voice application). We then 
say that it would be perfectly OK but not required (MAY) if the protocol 
was capable of a complete {setup/do work/shut down} cycle on shorter scale, 
down to a single interaction for one utterance.

> SHOULD for the framework (and correspondingly MAY for Server
The WG consensus was otherwise, but now you are the second set of folks 
commenting that we ought to water this down to SHOULD. I am personally 
inclined to keep this as a MUST, since adding this to the protocol later if 
not accommodated in the design up front could be very difficult. On 
apractical basis, a number of the candidate protocols (MRCP, RTSP) already 
do this, so meeting the MUST may not in practice be all that difficult.

Need WG feedback on this point so we can reach closure!

> the framework (see also point 7 on 'voicing').
Good point. Could you please SUPPLY TEXT.

> requirement may be to address 'guarantee of delivery' for ASR.
Where do you think TCP is ruled out in section 7?  I can't find it, sorry.

> believe MRCP may be over-specialized for use in VoiceXML environments.
Au contraire. If MRCP met the requirements we likely would not even be 
having this WG or this discussion; we would be having an MRCP WG or just 
asking the IESG to bless MRCP as a proposed standard.

To address the substance of your comment, there was WG consensus that none 
of the parameters in MRCP could be eliminated without losing some 
functionality that was deemed essential. This is not to say that the set in 
MRCP is complete by any means. We know it's not. It would be helpful if you 
could enumerate that parameters in MRCP that you do not believe are 
essential, keeping in mind that we want the speechsc protocol to have wide 
applicability which *includes* but is *not limited to* VoiceXML 
environments.

> by reference to another spec; we think these should be explicit in this
Would you suggest we do the same for everything in SMIL as well, which we 
incorporate by reference. I'm sympathetic to the pain it causes a reader to 
have to chase separate documents, but am reluctant to mass import text that 
is easily available and be more understandable in context.

If the WG wants to import this, I'll do it.

> unclear what it adds to the requirement on the framework in para 3.
I'm somewhat sympathetic to this view, but on balance I'm inclined to keep 
these things because the do very much inform the protocol design, in this 
case how important it is to presume caching of grammar definitions when 
there is a long-lived control channel.

> 18. (para 3) It is unclear what burden this requirement places on the
It says that if the protocol is purely transactional with no 
cross-transaction state it may run afoul of SV servers who fail to work 
right if the protocol resets their state on each interaction. The 
requirement is stated this way so that the protocol evaluators/designers 
think about the underlying operation of the SV servers when considering the 
interaction models that the protcol needs to support.

Would you like to take a crack at expressing this better than the existing 
text?

> called out in advance of the rationale.
Right. We'll to take a crack at this based on this comment and a similar 
comment from someone else. One good suggestion is to pitch the term 
"dual-mode" and say "full-duplex" instead, which may go a long way to 
helping get across the substance.

> 'defining' DSR coding schemes?
Yes. In addition we won't even discuss them or do any 
investigation/evaluation of various DSR schemes. They're just anohter codec 
to us :-)

[fin]
Dave.
------------------------
David R. Oran
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: [email-masked]

---

From: "Jeff Kusnitz" <[email-masked]>
Date: Fri, 20 Sep 2002 09:39:14 -0700

With respect to SR vs SIV, as the industry
understands that Speaker Recognition means speaker identification and verification,
I don't see the motivation to coin a new phrase for it.  The fact
that it's acronym is misleading is a separate issue (which I tend to agree
with).

Jeff

"David R. Oran" <[email-masked]>

Sent by: [email-masked]

09/20/2002 08:23 AM

To:
Salvador Neto <[email-masked]>,
Eric Burger <[email-masked]>, [email-masked]

cc:
Hsiao-Wuen Hon <[email-masked]>,
Stephen Potter <[email-masked]>

Subject:
[Speechsc] Re: Comments on draft-ietf-speechsc-reqts-00.txt

Thanks for your careful and comprehensive review.
This is exactly the kind

WG - please continue this discussion on the list - we want to see if we
can

protocol analysis work.

Done.

be carried over TCP. The concern over broadening the coverage beyond RTP
is

blocking.

I like this suggestion (despite my proposing a different acronym in my
note

Please do. ASAP.

Would be satisfactory?

On a more philosophical note, these requirements are meant primarily to
be

consumed by the people undertaking the analysys of existing protocols,
and

as a measure against which to evaluate any protocol the WG proposes to
the

since they are relevant to the design of a SPEECHSC protocol and point
out

unless this was considered in the design. The intent of the requirement
is

We'd appreciate any attempt you could make to capture this better than
the

existing text.

view.

which were intended. I could of course be wrong. WG - help us out here
-

consensus.

"playback", and note that "synthesis" is not quite
right either because the

how requirments on the protocol relate to things the servers are assumed
to

ameliorate this problem it might cause other problems in understanding
how

change?

clear to me (I know this isn't too  helpful). What we are trying to
say is

that it is pretty important (SHOULD) that the protocol be able to keep
its

inclined to keep this as a MUST, since adding this to the protocol later
if

Where do you think TCP is ruled out in section 7?  I can't find it,
sorry.

functionality that was deemed essential. This is not to say that the set
in

MRCP is complete by any means. We know it's not. It would be helpful if
you

environments.

Would you suggest we do the same for everything in SMIL as well, which
we

incorporate by reference. I'm sympathetic to the pain it causes a reader
to

have to chase separate documents, but am reluctant to mass import text
that

think about the underlying operation of the SV servers when considering
the

text?

"dual-mode" and say "full-duplex" instead, which may
go a long way to

to us :-)

[fin]

Dave.

------------------------

David R. Oran

7 Ladyslipper Lane

Acton, MA 01720

Office: +1 978 264 2048

VoIP: +1 408 571 4576

Email: [email-masked]

Speechsc mailing list

[email-masked]

---

From: Sarvi Shanmugham <[email-masked]>
Date: Fri, 20 Sep 2002 10:36:53 -0700

comments inline.

> we hope SpeechSC will be open to contemplate such alternatives.

Though RTP is used extensively,
Section10 says: "The protocol assumes RTP carriage of media. Assuming
session-
   oriented media transport, the protocol will use SDP to describe the
   session. "

So I believe we would be using something like SDP to describe media and
hence does not necessarily tie us to RTP.

> Identification/Verification (SIV).

I agree

> it a must-have. So we suggest this requirement should be a SHOULD.

The basis for this is that when a client is dealing with a single server
entity for ASR/SIV etc. the client should not have to send it 2 separate
streams. I believe this is a MUST and this option is required. But the
client, if it chooses to, can make open separate sessions to the same server
for ASR and SIV.

> audio files, it may be useful to address this scenario more explicitly.

SSML allows the interleaving of text and audio and hence in my mind it
is an already implied SHOULD requirement.

> 'defining' DSR coding schemes?

Yes. The WG will not be defining new codecs. But the SpeechSC protocol
should be able to work with differnt codecs including the DSR codec(s) being
defined by the various other groups. Here to, choice to use a generic
descrption mechanism such as SDP to describe the audio covers bothe the
treansmission media and the data/codec types of the media.

Thx,
Sarvi

---

From: Sarvi Shanmugham <[email-masked]>
Date: Fri, 20 Sep 2002 11:07:15 -0700

> I, for one agree, and suspect the Wg would not have any problem with this.

Agreed

> Rapid WG and AD feedback on this particular issue is important, I think.

As I mentioned in an earlier email. Though RTP would be the prefered way of
transmitting media and hence may be extensively refered to the documents and
hence a SHOULD requirement, the fact that we would be using generic mechanism
such as SDP allows the client and servers which MAY support other mechanism
such as TCP to work as well.

So I am inclined to leave RTP as a MUST and other mechanism to carry media and
described through SDP as a MAY.

> adopt this acronym in the next revision of the draft.

Agreed.

> many pits others have fallen into.

Agreed.

> WG members, please weigh in here.

As I mentiioned in an earlier mail. I feel this is a MUST requirment for
efficiency in big systems such as VoiceXML servers. But at the same time I
don't see this MUSt requirment preventing clients from setting up separate
sessions for each session or each resource within the session and sending them
duplicate media.

> Need WG feedback on this point so we can reach closure!

I believe these are a MUST define for the protocol to address or specify. In
the protocol definition though, as defined in an earlier comment(point 10), we
could make a conformance choice and enumerate the individual features as a
SHOULD or MAY. I have no problem with that.

> If the WG wants to import this, I'll do it.

Though I do sympathize with the comment, I'm fine with the way it is.

I agree

Sarvi

---

From: Qiru Zhou <[email-masked]>
Date: Fri, 20 Sep 2002 14:17:50 -0400

Although Speaker Recognition has been used widely in academic world to
refer both speaker identification (SI) and speaker verification (SV),
In engineering or productization world, they have the following differences
that need attention to define a protocol/interface to support them both:

1. SV is to authenticate a claimed user identity that is known to the system
by the user registration. Basically, it is one user voiceprint matches to one
pre stored voiceprint algorithm. Therefore, the search space of SV is quite
limited and fast to process (less CPU cycles, small data footprint). This is
similar to a text based (password, secure token) authentication system. But
a practical system may need to process large amount of SV requests at one
time.

On the other hand, since SV is mostly used in security access applications,
Security considerations on voiceprint storage and transport, authentication
certification passing are required for a protocol to support it.

2. SI is to find the user identity via her/his voice samples in a community
of users. The search space is larger compare to SV, unless you only want to
identify a user from a group of few (which may not be a distributed system
case). I don't have a good use case on this in my mind. I'd like to hear
one if anyone have a story. One thing that I can think is to use SI to
identify a user for a desktop computer.

Another useful technology is called language identification that is speaker
independent and doesn't need user enroll to the system.

I don't think it will be big problem to put both SI and SV in Speaker
Recognition category. But SR is a confusing acronym, as Jeff said.

-- Qiru

Jeff Kusnitz wrote:
> 
> With respect to SR vs SIV, as the industry understands that Speaker Recognition means speaker identification and
> verification, I don't see the motivation to coin a new phrase for it.  The fact that it's acronym is misleading is a
> separate issue (which I tend to agree with).
> 
> Jeff
>

---

From: "Brian Wyld" <[email-masked]>
Date: Fri, 20 Sep 2002 21:43:20 +0200

my 2c? worth (don't know if that's worth more or less that 2c$) below.

[Brian Wyld] [[email-masked]]
[Directeur General R&D]
[Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
[advanced solutions for telecoms and IT services]

> I, for one agree, and suspect the Wg would not have any

Can we explicit any exact requirements that flow from including such a
scenario? (apart from the RTP discussion..)

> > SpeechSC depends on RTP may mean that it depends on UDP.
[snip]
> the RTP dependency for the reasons cited above.

IMHO we should stick only with RTP - given it can be carried over TCP, and
can contain any payload you like via SDP definitions/rtpmap. I think we
would need to see a specific case where a speechsc scenario didn't work to
change this.

We could add a note that RTP/UDP is suited for RT type use, and RTP/TCP for
store-n-play type use scenarios?

> adopt this acronym in the next revision of the draft.

Hmmm. Given points raised by others, I'd be more inclined to say SI/SV (to
reinforce the point that its two potential different functions (and hence
one may have an SI-only or SV-only server), but that may be considered to
have simiar requirements.

[snip]

> many pits others have fallen into.

Agreed. One can't include all other related docs, but one can't ignore them
either - if you don't want to run off and read related documentation maybe
you're not up to speed enough to make a comment (a QUESTION, yes, to which
the ANSWER might be a pointer to the relevant part of the relevant spec....)

[snip]
> was this is a MUST requirement. Let's revisit this given we

MUST for me...

[snip]

> down to a single interaction for one utterance.

I think I already proposed clarification text (although given the resulting
questions it maybe wasn't as clear as I thought...:-()

> do this, so meeting the MUST may not in practice be all that

Keep it MUST. Also, generally speaking I'd avoid having too many
SHOULDs/MAYs on such protocol design points as this is a great way to avoid
interoperability if you get my point....

[snip]

> applicability which *includes* but is *not limited to* VoiceXML

Agree can't eliminate any of the parameters, rather IMHO the protocol needs
to ensure a flexible and extensible way to add parameters in the future
(cause we'll never anticipate them all). This could simply be like the
rtsp/http/mrcp headers system (where you can add them as you want and the
server ignores those it doesn't understand).....

In the speechsc protocol there should be a common basic set that all servers
MUST understand....

[snip]

[fin]

---

From: "Eric Burger" <[email-masked]>
Date: Tue, 24 Sep 2002 12:28:00 -0400

I can easily see a difference in operation between Speaker Identification
and Speaker Verification.  However, my question to the speech community is,
"Is there a protocol difference?"

For example:

1. For Speaker Identification, the client needs to specify an individual
speaker template.  For Speaker Verification, the client needs to specify an
individual speaker template.
==> They look the same to the protocol.

2. For Speaker Identification, the client needs to specify an individual
speaker template.  For Speaker Verification, the client needs to specify a
set of potential individuals.
==> They could look the same to the protocol.

3. For Speaker Identification, the client needs to specify an individual
speaker template.  For Speaker Verification, the client needs to specify a
set of groups, as well as indicate specifically that this is a Verification,
not Identification, operation.
==> They are probably different operations.

So, for the speech community: which one is it, really?

> -----Original Message-----
> From: Qiru Zhou [mailto:[email-masked]]
> Sent: Friday, September 20, 2002 2:18 PM
> To: Jeff Kusnitz
> Cc: David R. Oran; Eric Burger; Hsiao-Wuen Hon; Salvador Neto;
> [email-masked]; [email-masked]; Stephen Potter
> Subject: Re: [Speechsc] Re: Comments on draft-ietf-speechsc-reqts-00.txt
>
>
> > With respect to SR vs SIV, as the industry understands that
> Speaker Recognition means speaker identification and
> > verification, I don't see the motivation to coin a new phrase
> for it.  The fact that it's acronym is misleading is a

---

From: "Brian Eberman" <[email-masked]>
Date: Tue, 24 Sep 2002 14:37:18 -0400

I think speaker identification and verification can be done with exactly the
same protocol.

The operations are:
1) add the next utterance you see to the enrollment list to update the model
2) get the model so it can be centrally stored (maybe this isn't supported)
3) verify or identify an utterance against a set of speaker models.

Frankly except for #2 verification and identification look a lot like speech
recognition.

-Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Eric Burger
Sent: Tuesday, September 24, 2002 12:28 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Speechsc] Re: Comments on draft-ietf-speechsc-reqts-00.txt

For example:

---

From: Qiru Zhou <[email-masked]>
Date: Sat, 28 Sep 2002 04:59:52 -0400

It should be:

For Speaker Verification, the client needs to specify an individual
speaker template.  For Speaker Identification, the client needs to
specify a set of potential individuals (may plus other audio source
identities), as well as indicate specifically that this is an
Identification, not Verification, operation.
==> They are probably different operations.

Based on what we defined in our research. Let me give use cases for
SV and SI here:

1. Speaker verification:
This is a two session process in most common SV usage:

Enrollment:
The SV application collects certain amount of speaker's voice samples
(explicitly or implicitly) to build speaker template (or voice print.
In Bell Labs technology, we build speaker dependent HMMs). In implicit
case, multiple enrollment sessions may needed to collect enough samples
to build the templates in good quality. Also you need to provide a
user override mechanism if retrain the template is needed.

Verification:
The SV application collects a utterance sample from the speaker, and
compare to the template that in the profile of the speaker claimed
identity to see if it is the right match. This process require the
server load the template of the claimed speaker from storage (database,
etc.). And a compare template (in most of the HMM cases, we call it
cohort model) is needed to perform a likelihood ratio test (in the
scope of decision theory.)

In general, SV may apply to large number of speakers. A voice print
database interface abstraction (in BioAPI case, BioAPI DB section.)
is required. Also a large number of SV applications use fixed phrases
(per speaker) or digit strings for verification utterance.

Please refer to BioAPI Consortium (http://www.bioapi.org) BioAPI 1.1
(ANSI/INCITS 358 standard) on this model. I believe it is a good API
and model (Dave, this is the reference you want: "BioAPI Specification 1.1,
The BioAPI Consortium, March 16, 2001".)

2. Speaker Identification:
I have hard time to find a SI service application use case since its
complexity to deal with large number of speakers. One of the commonly
use case in research is speaker identification in audio indexing, where
the speech signal is a multi speaker, spontaneous conversation scenario.
The voice samples for building speaker templates and samples
for SI are text independent in most of the cases. The LDC TSID database
description (http://www.ldc.upenn.edu/Catalog/LDC99S83.html) gives a
simple and  good example on how to perform a SI experiment.

There is no explicit user enrollments in this use case.

In another SI use case, an application can use the same explicit
enrollment process as SV to build N user's template. Then once a
speaker in this N user group talk to the app, the app may prompt the
speaker for a fixed pass phrase to compare all N template to see which
is the best match. This case is a specific N-classification problem.
Which is easy to cover by a SV protocol, with a different decision
logic (could be outside the the speech server protocol).

From protocol or API concerned, I consider both SV and SI be add-ons to
base ASR(or SR) protocol/API. Since both of them can be presented as
special cases of ASR, with extra decision logic. If we only care of
the second SI use case, the same protocol with a minor extension can
cover both.

-- Qiru