Subject: [Speechsc] WGLC for Requirements draft

From: "David R. Oran" <[email-masked]>
Date: Tue, 03 Sep 2002 17:32:58 -0400

I'd like to begin Working Group Last Call for 
draft-ietf-speechsc-reqts-00.txt.  Last call will close on Sept 20th.

Comments to the list, as usual. Thanks.

Your chairs,
Dave and Eric.

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

---

From: "Brian Wyld" <[email-masked]>
Date: Sat, 7 Sep 2002 23:25:46 +0200

Hi,

My comments on the requirements draft are below. If they cover discussions
already hashed to death at the IETF meeting, my apologies - no doubt someone
will set me straight....

Document general:
 - it would be nice to number the requirements within the sections (as it
done in section 5 but not in 6/7/8/9 to allow for easy reference.

Section 4. Framework

What is mechanism by which RTP sessions are identified by the speechsc
server and related to the speechsc session? Is it purely by IP/port or by
some RTP session id?

In the diagram, the entities that can initiate a speechsc session with a
server are shown as the AS and MRE. However, it is also noted in the text
that the MRE can be further decomposed into a MG/MGC type pair. I believe
this would be useful to show, as it seems to me that the session/RTP
identification point above may be further complicated by such a
decomposition.

Section 5 : General requirements

 - propose to add a requirement "SPEECHSC framework MUST define a single
protocol for all of its MUST requirements ie cannot define to use existing
protocol A for TTS, and a new protocol B for ASR or SR".

The aim of such a requirement is to ensure that a speechsc implementor does
not have to create/purchase multiple protocols for speechsc support.

To achieve this, the requirement of 5.3 (no existing protocol duplication)
may be broken for TTS in order to ensure a unified protocol for ASR/SR
operation. (but its already a SHOULD NOT rather than a MUST....)

 - add new sub-section in 5 that covers all control
channel/session/operation requirements (including and extending the
paragraph about sessions in section 6).
   - explicitly define that SPEECHSC protocol :
  MUST allow a 1:N mapping between session and RTP channels ie a single
session may include an outbound RTP channel for TTS, an inbound for ASR and
a different inbound for SR (eg if processed by different elements on the
MRE).
  MUST define how RTP sessions included in a speechsc session are identified
  MUST be capable of using a single control channel during :
    - a single session
    - multiple sessions serially
    - multiple sessions in parallel
  MUST be capable of using a single session for
    - a single operation of a single type (single utterance recognition)
    - multiple operations of the same type (use of TTS channel during a
call)
    - multiple operations of different types (TTS/ASR server, ASR/SR server)

  - a speechsc server MUST allow all of the above possibilities except the
last (ie a TTS only speechsc server is ok).

 - propose to add a requirement that SPEECHSC MUST define a mechanism to
allow a speechsc server to be interrogated by a client about its
capablilities. The set of capabilities that can be verified MUST include:
    - server type : TTS or ASR or SR or combo
    - hint about relationship with other servers (load balancing,
multi-vendor compatibility, etc)
    - languages supported
    - implementation or not of the SHOULD items in the protocol
   NOTE: this might be redundant with 5.5 if these capabilities form part of
the search requirements for a service location request.

Section 7 : ASR requirements

 - add requirement that speechsc provides a way to convey the grammar
language(s) explicitly without requiring parsing of the grammar itself
(required to be able to create a generic speechsc server module that passes
the actual ASR processing to another element, based on the language
required)

 - change SHOULD to MUST for the requirement for SPEECHSC to have a method
to instruct the capture of the media stream by the ASR server, and add that
the ASR server SHOULD implement it (it may communicate its
non-implementation to a client) [ie the protocol must define the mechanism,
but the server may not implement it]

 - (last para in seciotn 7) change "The ASR Server SHOULD support sharing
grammars across sessions...." to "The SPEECHSC framework MUST support a
means of requesting the sharing of grammars across sessions....", and add
that "ASR server SHOULD support this functionality". [ie the protocol must
define the mechanism, but the server may not implement it]

Section 9 : Dual-Mode Requirements

I think that this section could be generalised to state that:
 - SPEECHSC MUST support multiple simultaneous operations on the same
session to the same server
   [eg case of "speaking detection" and ASR functions on same server, or SR
and ASR on the same server, or ASR and TTS on the same server]

 - SPEECHSC MUST support duplication of RTP streams to servers and MUST
support multiple simultaneous operations on the same session to different
servers using these duplicated RTP streams
   [eg case of SR and ASR which are on different servers, to support the
dynamic challenge example given]

Section 10 : Thoughts...

Just a comment on the item about TTS being likely to be coverable by RTSP++
or a SIP NA type spec and ASR/SR being the focus of protocol work - this is
why I think we need an explicit requirement that the speechsc result
protocol is a single protocol and not 2 or 3. Even if RTSP is "almost" right
for TTS, if it cannot be extended in a reasonable way for ASR/SR then I
think it cannot be used for TTS. Duplication of "almost right" type protocol
functionalities is ok if it achieves a "higher" purpose (unified protocol
for speechsc) (ok, more of a religous point here but lets remember the poor
folks who have to implement this....)

Anyway, thats enough for now.....

Brian

[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]

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]]De la part
de David R. Oran
Envoye : Tuesday, September 03, 2002 23:33
A : [email-masked]
Objet : [Speechsc] WGLC for Requirements draft

Your chairs,
Dave and Eric.

---

From: "Eric Burger" <[email-masked]>
Date: Wed, 11 Sep 2002 11:29:23 -0400

in-line

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of Brian Wyld
[snip]
> done in section 5 but not in 6/7/8/9 to allow for easy reference.

Good idea.

> server and related to the speechsc session? Is it purely by IP/port or by

The requirement is that it is identified.  We're not up to specifying how,
yet.

> identification point above may be further complicated by such a

I don't see the complication -- an end-point is an end-point.  There is
nothing to say that it has to have the same IP address as the signaling
end-point.

> not have to create/purchase multiple protocols for speechsc support.

This has been beat a bit: ASR and SV have pretty much the same needs; TTS
has very different needs.  I might live with an "it would be nice if there
was a single protocol", but I wouldn't even elevate it to a SHOULD.  By the
logic given above, the protocol also should encompass session invocation
(SIP), data transfer (HTTP), and system monitoring (SNMP).  Rather than
standing at the precipice of the slippery slope, I would leave this one
alone.

> paragraph about sessions in section 6).

Can you give examples?

> a different inbound for SR (eg if processed by different elements on the

Probably OK.

>   MUST define how RTP sessions included in a speechsc session are

Out of scope: that's an implementation detail.  *That* we MUST identify RTP
sessions is a requirement.

>   MUST be capable of using a single control channel during :

Agreed.

>     - multiple sessions in parallel

These were beaten to death in Minneapolis.  The short answer is that if we
get there, great, but it is so unlikely to be sensibly done in practice,
we're not going to focus (or rat-hole) on it.

>     - multiple operations of different types (TTS/ASR server,

Does section 9 cover this?

> last (ie a TTS only speechsc server is ok).

What's wrong with an ASR-only or SV-only server?

> the search requirements for a service location request.

I think section 5.5 covers this.

> the actual ASR processing to another element, based on the language

Hmmm.  Need to hear from others on this one.

> but the server may not implement it]

Need to hear from others, especially the ASR vendors.  I like the idea.

> define the mechanism, but the server may not implement it]

Other votes?

> and ASR on the same server, or ASR and TTS on the same server]

This isn't already there?

> dynamic challenge example given]

Implementation; beyond requirements.

> folks who have to implement this....)

The problem is that we would be reinventing almost all of RTSP to support
TTS.  Let's leave it to the protocol analysis document to delve in to what
can work where.

---

From: Sarvi Shanmugham <[email-masked]>
Date: Wed, 11 Sep 2002 11:35:08 -0700

some responses inline.

> server and related to the speechsc session? Is it purely by IP/port or by

I believe this would be part of the protocol identification/definition which
would be the next phase of the process.

But I would venture to suggest that it wouldd be nice to use something like SDP
to describe the RTP pipe to/from the client to the speechsc server.

> not have to create/purchase multiple protocols for speechsc support.

Though I would love to see that too for simplicity sake, I don't think that
should be made a MUST or a SHOULD.

> a different inbound for SR (eg if processed by different elements on the

This should not be a MUST.
In fact if anything, I would suggest that SPEECHSC server should have to receive
only 1 incoming RTP stream for ASR and/or SV and one outgoing RTP channel for
TTS.
If at all, we want to allow this as an option, and the SPEECHSC server wanted
the same incoming RTP stream forked to 2 different points(ASR & TTS), this may
be achieved with something like an SDP with 2 different m-lines. But I' would
consider this as a MAY/option.

>     - multiple sessions in parallel

Not sure what you mean by single control channel during multiple sessions
serially or parallely. Could you please elaborate.

>     - multiple operations of different types (TTS/ASR server, ASR/SR server)

Within a single session established to a SpeechSC server(meaning a single
control session with an established RTP pipe), I agree we should be able to
allocate a recognition resource and do multiple ASR operations one after the
other. Within the the same session, we should also be able allocate a SV and do
one or more SV operations in sequence. When you are talk about parallely, if you
are refering to the case of having a SV and an ASR operation active parallely in
the  same session. I agree.
With TTS I would agree, parallel operation should be possible, IF we do end up
with a single protocol for ASR, TTS and SV.

> the search requirements for a service location request.

Agreed. I believe this covered in the requirements doc.

> the actual ASR processing to another element, based on the language

If this is setting some sort of default language, if the grammar doess not
contain a language, I would agree. But if a grammar markup does specify a
language it will always take precedence.
In any case, this should be a protocol design detail.

> but the server may not implement it]

I Agree

> define the mechanism, but the server may not implement it]

Is this for efficiency in a downloading and compiling large grammars?
Wouldn't caching fetched/compiledd grammars addrerss the problem. Would we still
need global or shared grammars, if we had caching and ways of controlling
caching of grammars on the speechsc server???

> and ASR on the same server, or ASR and TTS on the same server]

Are these different from previous comments in thiss email.
I believe this covered.

> dynamic challenge example given]

I believe this to be protocol definition detail.

> folks who have to implement this....)

Lets shoot to have a unified protocol, but not tie us down with a MUST. atleast
not yet.

Sarvi

---

From: "Brian Wyld" <[email-masked]>
Date: Thu, 12 Sep 2002 00:56:31 +0200

Hi Sarvi,

Some of your points are covered (I think) by my reply to Eric - other
responses below...

> De : [email-masked]
> [mailto:[email-masked]]De la part
> de Sarvi Shanmugham
> Envoye : Wednesday, September 11, 2002 20:35
> A : [email-masked]
> Cc : 'David R. Oran'; [email-masked]
> Objet : Re: [Speechsc] WGLC for Requirements draft
>
>
> some responses inline.
>
[snip]
> should be made a MUST or a SHOULD.

I'm ok to wait till we do the existing protocol comparison doc and see how
it comes out....

> consider this as a MAY/option.

True it might be a marginal case.

> serially or parallely. Could you please elaborate.

Multiple serial use
   - Open a control channel client->server
     - setup session A
        - execute 1-N operations (eg TTS generation)
     - close session A
     - setup session B
        - execute 1-N operations (eg TTS generation)
     - close session B
     - etc
   - close control channel

Multiple parallel use
   - Open a control channel client->server
     - setup session A
     - setup session B (C, D etc)
        - execute operation on A (eg TTS generation)
        - execute operation on B(eg TTS generation)
        - repeat until done
     - close session A
     - close session B
   - close control channel

> with a single protocol for ASR, TTS and SV.

Yup, thats what I meant.

[snip]
> caching of grammars on the speechsc server???

Caching achieves the same goal but the first user of the grammar pays the
compilation latency. Otherwise yes, I'm just requesting a means of providing
caching hints to the server.

> > Anyway, thats enough for now.....

And again, bedtime...

Brian

---

From: "Brian Wyld" <[email-masked]>
Date: Thu, 12 Sep 2002 00:45:33 +0200

comments on Eric's comments where appropriate below....

> De : Eric Burger [mailto:[email-masked]]
> Envoye : Wednesday, September 11, 2002 17:29
> A : [email-masked]; 'David R. Oran'
> Cc : [email-masked]
> Objet : RE: [Speechsc] WGLC for Requirements draft
>
>
> in-line
>
[snip]

> The requirement is that it is identified.  We're not up to

Ok, fine.

> nothing to say that it has to have the same IP address as the

Ok, it was just to be able to reinforce this point in the diagram.

> standing at the precipice of the slippery slope, I would

In some ways the resulting protocol will encompass elements from others - I
don't think its the case that all protocols must be orthoganal (sp?) to each
other (and certainly not the case that they are currently....)

However, probably verging on a religous war here, so I'm content to leave
that till we're further on....

> > paragraph about sessions in section 6).

Well, the requirements that followed were my examples...

[snip]
> sessions is a requirement.

Fair enough.

> we're not going to focus (or rat-hole) on it.

Hmmm. Not to drag pre-existing protocol implementations into it, but I know
of at least one implementation that opens its control channel (==TCP socket)
at startup to each server configured, and uses this same channel for ALL
session messages to that server (ie, single control channel for multiple
sessions in parallel). IMHO there are interesting efficiency gains to be
made over open/close of the control channel for each session.....

> Does section 9 cover this?

Effectively, but I wanted a re-grouping of all session lifecycle related
items in a single section....

> What's wrong with an ASR-only or SV-only server?

Nothing, the TTS was just an example of a single mode server....

> I think section 5.5 covers this.

Ok. Maybe just needs a specific clarification?

> Hmmm.  Need to hear from others on this one.

Ok. It's a minorish point....

> Need to hear from others, especially the ASR vendors.  I like

Ok. Note that I make the difference between what the speechsc protocol MUST
cover (ie what this WG has to do) and what a particular implementation of an
ASR server must do to be complient....

> > define the mechanism, but the server may not implement it]

Point is same as above - I want protocol support for the feature but am
willing to see it as a "plus" for a specific ASR vendor....

> This isn't already there?

Yes, I was just trying to generalise from the "dual" mode to say we might
have "n-mode" servers (n 1-3 I guess...)

> Implementation; beyond requirements.

Is there no impact on the protocol? I thought there might be some sync
required? Maybe leave until the detail emerges.

> TTS.  Let's leave it to the protocol analysis document to

Fair enough, it was just my 2c anyway....

Brian

---

From: Sarvi Shanmugham <[email-masked]>
Date: Wed, 11 Sep 2002 17:50:26 -0700

>         - execute operation on B(eg TTS generation)

By Control channel, if you are refering to a TCP connection, where by multiple
Speechsc sessions are setup and executed over single TCP session between the
client and the server.
I would agree.

> caching hints to the server.

I agree.
Please refer to draft-shanmugham-mrcp-02.txt for how MRCP provides caching hints
to the server.

Thx,
Sarvi

---

From: "Brian Wyld" <[email-masked]>
Date: Thu, 12 Sep 2002 09:38:20 +0200

Hi Sarvi,
> Speechsc sessions are setup and executed over single TCP

I didn't want to prejudge the use of TCP :-), but yes.

> Please refer to draft-shanmugham-mrcp-02.txt for how MRCP

Indeed, MRCP covers this point, I just wanted to ensure the requirements doc
captured the need. (in fact I was thinking about the requirement being to
have perhaps an explicit "pre-define this grammar" method as MRCP proposed)

Brian

> De : Sarvi Shanmugham [mailto:[email-masked]]
> Envoye : Thursday, September 12, 2002 02:50

---

From: "Eric Burger" <[email-masked]>
Date: Tue, 17 Sep 2002 18:44:20 -0400

Now I get it: said colloquially, "Don't make the mistakes of HTTP 1.0".  Do
we need to explicitly state the protocol MUST/SHOULD allow for multiplexing
sessions on a persistent, reliable connection, or is it covered by the
"protocol should be efficient" requirement?

> Sent: Thursday, September 12, 2002 3:38 AM
> To: 'Sarvi Shanmugham'
> Cc: 'David R. Oran'; [email-masked]
> Subject: RE: [Speechsc] WGLC for Requirements draft
>
>
> Hi Sarvi,

---

From: "Brian Wyld" <[email-masked]>
Date: Wed, 18 Sep 2002 12:56:28 +0200

Hi,

Indeed, I should have used the HTTP1.0 example. I think its good to make it
explicit (one can never be TOO clear...)

When do you anticipate a revised requirements doc? Particularly for the
protocol comparisons, its good to have each req with a specific label....

A+

Brian

> de Eric Burger
> Envoye : Wednesday, September 18, 2002 00:44
> > From: [email-masked]
> [mailto:[email-masked]]On Behalf
> > Of Brian Wyld

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 18 Sep 2002 10:45:49 -0400

--On Wednesday, September 18, 2002 12:56 PM +0200 Brian Wyld 
<[email-masked]> wrote:

> Hi,
>
> Indeed, I should have used the HTTP1.0 example. I think its good to make
> it explicit (one can never be TOO clear...)
>
Good.

> protocol comparisons, its good to have each req with a specific label....
I plan to wait for last call to close on the 20th, go through the comments, 
address each, and have a revised draft within 2-3 days. Depending on 
whether any of the comments are deemed controversial enough to require 
further discussion (so far none are in that category IMO), I will either 
just restart last call, or send the revised draft to the IESG for approval 
and publication.

That plan sound good?

>> > > > > > Anyway, thats enough for now.....

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

---

From: "David R. Oran" <[email-masked]>
Date: Fri, 20 Sep 2002 09:18:05 -0400

Thanks for your comprehensive and detailed review of the requirements 
draft. This is exactly the kind of feedback we want for last call (although 
earlier would have been even better :-) )

Responses and comments inline.

--On Friday, September 20, 2002 5:22 AM -0400 Qiru Zhou 
<[email-masked]> wrote:

> Hi, speechsc WG,
>
> My comments on the SPEECHSC requirements draft. Also I am interested in
> to volunteer for MRCP if needed.
>
> -- Qiru
>
> 1.   Abstract
>
> Speaker identification and speaker verification are quite different
> technologies. They require significant different application
> implementations.
>
> Suggestion:
>
> change
>    automatic speech recognition, speaker recognition (which includes
>    both speaker identification and speaker verification) and
> text-to-speech. to
>    speech recognition, speaker identification, speaker verification, and
>    text-to-speech.
>
The text is the way it is because throughout the rest of the draft we use 
the term "speaker recognition" to apply to both. I am averse to changing 
this unless we also decide to have separate sections with separate 
requirements for the two. If there are in fact a different set of protocol 
requirements for the two applciations (as opposed to just the different 
implementations you cite above) I am happy to do that if someone will 
enumerae the differences in the requirements.

> 3.   Introduction
> text "Automated Speech Recognition (ASR), speaker recognition (SR)" is
> confusing since in lot of literature SR means speech recognition.
>
> Suggestioin:
> change to "Speech Recognition (SR), speaker identification (SI) and
> speaker verification (SV)".
>
This is closely related to the issue above. Let's deal with them together. 
If we decide to not change the wording, we could decide to just change the 
acronym from SR to something else, such as SPR for "SPeaker Recognition".

> 4.   SPEECHSC Framework
> It is not clear to me what the relation of speechsc to MRCP is. From
> document "draft-shanmugham-mrcp-02", speech components (SR, SI, SV, TTS,
> etc.) are plug-in components to MRCP. And MRCP provides underlining
> control carrier protocol to make speech components distributed. Is this
> picture still hold? In my opinion, this framework is good and it
> reduces many redundancy between speechsc and MRCP.
>
Yes, the framework still holds (and the WG seems to have consensus that it 
is the appropriate framework). What you may be missing is that this draft 
is meant to be input to the evaluation of existing protocols and based on 
that, either the selection of an existing protocol, the modification of an 
existing protocol, or the design of a new protocol. MRCP is obviously one 
candidate as the starting point. So the redundancy between the framework 
which produced MRCP and the SPEECHSC framework is not coincidental.

That said, the idea of having the various types of services as "plug-ins" 
to a general-purpose protocol is a very good one, and such a protocol 
structure would IMO be a plus to be noted in the protocol evaluations.

I'm not sure this addresses completely the thrust of your comment. If not, 
please elaborate, or even better SEND CANDIDATE REPLACEMENT TEXT.

> Also I believe that specify speech components deal RTP streams only
> restricts the usability of speechsc protocol. In many none telephony
> or VoIP applications, speech input/output many not need to be send
> via UDP, or they are more efficient to be send via other means of
> network transport, such as TCP, or even a whole utterance at once.
> Examples are wireless PDA speech dialogues, speaker verification
> enrollment and verification, internal network stream transport such
> as speech server to internal media servers and media gateways.
>
We did not consider media transport protocols other than RTP. This was 
intentional. It seems you are asking us to revisit this. What does the WG 
think, keeping in mind that RTP can be sent over TCP as well as UDP for the 
kinds of environments Qiro cites.

> In general, most of the current speech engines deal only buffered
> audio blocks. It will be easier to specify RTP pack/unpack process
> outside speech components as a separated module which deal general
> audio streams. RTP pack/unpack module is also reusable for other
> media processing, such as voice/audio recording/playback, etc.)
>
This seems like a good way to build your speech server, but (a)what is the 
requirement behind this, and (b)isn't this an implementation detail 
independent of the protocol?

> 5.   General Requirements
>
> 5.4.     Explicit invocation of services
> It will be good to have an use case here to explain the IAB OPES
> compliance. It is hard to me to understand the implication here.
>
Did you read the OPES documents? We can certainly add an example of what 
would be non-compliant; such examples are relatively easy to construct (all 
you need is a stateful intermediary that neither the client nor the server 
wanted in the path).

> 5.5.     Server Location and Load Balancing
> I'd like to specify here the speechsc framework SHOULD be aware
> of server location and load balancing, instead perform these
> itself. The actual server location and load balancing should
> be out of the speechsc scope.
>
I'm not sure exactly what you're saying here that is different from what is 
in the text. Could you say exactly what you think is different, or even 
better SEND CANDIDATE REPLACEMENT TEXT.

> 5.6.     Simultaneous services
> Ths requirement implicates the following cases:
> 1. one input voice stream can be consumed by several speechsc
> devices, such as SR, SI and SV, recording, etc. All these
> processing are independent to each other.
>
> 2. A single speechsc device can do SR, SI, SV, etc. on same
> audio input. And SI/SV may depend on SR results.
>
> Simultaneous or parallel are proper words here. It is application
> dependent. I suggest change ?5.6 Simultaneous services? to
> ?Media stream multiprocessing? and remove ?in parallel.?
>
I'm afraid I'm not following you completely here. The requirement clearly 
states the need to be able to perform multiple services in parallel. Given 
that you can always do this with separate instances of the protocol 
emanating from one client, the implication of the requirement is beyond 
that, to allow one instance of the protocol to express multiple services be 
preformed on the same RTP stream. Is that what you're getting at? If so, we 
can try to be more explicit in the text.

> 6.   TTS Requirements
> Suggest change  ?to playback text as voice in an RTP stream.? To
> ?to synthesis text as speech in a packetized audio stream.?
>
I'm not enthusiastic about this change, for two reasons:
(a)the discussion above on RTP versus being agnostic about the media 
transport, and (b)The requirement to "synthesis"[sic] is a requirement on 
the server and not the protocol/framework. The protocol doesn't much care 
if you actually do synthesis or just match the input text to a canned audio 
file.

> ?reading? is not a good word to describe TTS synthesis.
> ?synthesis? is more accurate. Also ?playback? or ?output?
> are acceptable.
>
I like "playback". I'll make this change as "The TTS Server MUST support 
the playback of plain text as speech.  For playing back..."

> What is the definition of ?document type of the text to
> be processed? here? The document encoding, format, or language?
>
I believe we are just re-using W3C terminology here. Brian(s), Stephane, 
could one of you help out here?

> I am not sure why a TTS server needs "VCR Controls" functions.
The glib answer is because the WG thinks so.

> Is this refer to the audio stream already produced by a TTS
> server, Or the text before input to a TTS server.
How the server does this is an implementation detail. From the point of 
view of the protocol, the control is via markers in the markup.

> I don't
> know how do you specify ?time mark? accurately on the input
> text.
If you have both the input and the output this would appear (at least to 
me) to be pretty strightforward).

> If the text is already produced by TTS, it seems to be
> more logical to use an audio player to provide ?VCR? or
> tape player functions. These functions can be used for other
> audio source as well. It is more complicate and impractical
> to implement the ?VCR? functions redundantly.
>
I'm not following you here. The client of the speechsc protocol might very 
well BE an audio player. The model here is very much like the RTSP control 
model, where the media processing is in the client and the media 
generation/storage is on the server. Clearly, unless you can cache all 
output at the client some control mechanism is needed in the protocol to 
control playback. Caching at the client (or alternatively, in a separate 
"audio server" is infeasible in many cases - you may have just told the TTS 
server to read you War and Peace.

> 7.   ASR Requirements
>
> Reference [15] means: ?The ASR Server MUST support the VoiceXML
> Speech grammar specification for speech recognition [15].? Is
> XML specification means that we only want to support XML format
> of SRGS, not ABNF?
>
No, I think is says we MUST support SRGS, not that we only want to support 
that. Another requirement is for extensibility to other forms. The purpose 
of the requirement is to ensure a non-null intersection of capabilities 
between clients and servers, while keeping the set of 
mandatory-to-implement things as small as feasible. Does this address our 
concern?

> In server based speech applications, many grammars (especially
> Large grammars) are provided by the application server instead
> of a client. For example, it is impractical to require a client
> Provide a company name dialing list via network connections.
> Also this may create security issues.
>
We require the ABILITY to specify the grammar by either value (the cas eyou 
cite here), or by reference. If the "by reference" mode does not address 
your concern here, could you elaborate a bit on why?

> If SPEECHSC is inter operable with VoiceXML or a new coming
> multimodal markup language (SALT, XHTML+VXML, etc.), Should
> we need to support all MUST parameters from VXML, etc.?
>
See above on minimal but non-null intersection. Clearly if we put a MUST in 
here with a normative reference to some other document, and that document 
in turn has MUST statements, those requirements are recursively 
incorporated into ours. Or do I misunderstand you here?

> ?capture the input media stream? is not a function of an
> ASR server. It should be achieved by a audio recorder and
> media database support.
The idea here is twofold:
a)that you do not have to send a separate copy of the RTP stream somewhere 
else
b)that you can tell the speechsc server via the control channel to do this, 
so that it can annotate and corellate the captured audio with its own 
actions.

?later analysis and tuning? are
> functions outside of a runtime ASR engine.
Agreed, but where do you get that the actual analysis and tuning functions 
are requirements of the protocol. Could you suggest replacement text that 
is clearer?

> ?grammar sharing? is a speech engine implementation and performance issue
> which may not be necessary to specify in SPEECHSC.
Agreed. However, some WG members argued persuasively that this requirement 
does have implications on the protocol design (e.g. ability to remember 
grammar sets across sessions) and I tend to agree.

> Also a VoiceXML
> compliant SR engine need to support rule import/export, multi-grammar
> in session as well.
>
Good point about multiple grammars. On a quick scan I didn't see anything 
explicit about specifying multiple grammars at once, although I believe the 
WG intended such. How about a requirement along the lines of

"The SPEECHSC framework must allow multiple grammars to be specified to be 
applied to the same input RTP stream."

> 8.   Speaker Recognition Requirements
> Again, it is more proper to separate speaker verification (SV) and
> speaker identification (SI).
>
Please specify what speechsc reqirements differ between the two and then we 
can address the desirability of making the separation.

> Both SV and SI needs voice print database that is external to the
> engine (a speech engine should not carry a gigabyte or terabyte
> media database with it. If SPEECHSC supports SV and SI, a voiceprint
> database interface MUST be specified.
>
I don't think this is within the charter of SPEECHSC. I tend to agree that 
a standardized database interface for voiceprints is something quite 
desirable, but I suspect that the IETF would eschew work in this area due 
to lack of expertise in database interfaces/protocols.

> Also there is an ANSI BioAPI that address the SV and SI interface
> issues has been followed by biometric companies. We need to look
> into this to make SPEECHSC compatible with it. BioAPI also address
> other means of biometric identifications that are MRCP related.
>
Good idea to look at this. Can you give me a reference to put in the 
references section?

> I don't think the last two paragraphs are necessary since these
> are application specific. Again, audio recording should not be a
> speech engine function.
>
In the case of multi-utterance, I believe the WG consensus was otherwise. 
The feeling was that while the functions themselves are application and 
implentation specific, the protocol design can make this easy, hard, or 
impossible depending on what state is kept, whether the state is kept on 
the client or server or both, and whether that state is externalizable or 
opaque.

In the case of audio recording, the intention is that the CONTROL of audio 
recording be required of the speechsc protocol, because of the need for the 
server (as opposed to just the client) to corellate the recorded stream 
with its own SV/SR actions. If you still feel this is misguided, try again 
to make that case and we'll see whether this view persuades the WG to 
change or eliminate the requirement.

> 9.   Dual-Mode Requirements
> It is clearer to say ?full duplex speech processing requirements?,
> instead of ?dual-mode?.
>
This strikes me as a good change. "Dual mode" never put the right image in 
my mind, whereas "Full duplex" seems to capture it. Any objections to this 
change?

> Full duplex speech processing requires precise in/out audio
> Synchronization, audio play interrupt, echo cancellation, speech
> recognition engine part of speech event generation, etc. These
> should be addressed in SPEECHSC to support these advanced speech
> processing functions.
>
I follow the need for precision in all of these except echo cancellation. I 
think that in fact they are covered in the text. If you don't see this, 
could you PROVUDE TEXT?

(The reason I disagree about precise synchronization of ecan is because in 
general it is infeasible due to the 1-3 second convergence time of 
state-of-the-art echo cancellation algorithms. You can't maintain real-time 
responsiveness with 1-3 seconds added to the control loop).

> 11.    Security Considerations
> For speaker verification/identification in a distributed environment,
> voiceprint database security and integrity MUST be addressed to
> support commercial applications.
>
Agree, however doesn't the existing text cover this? It says:
"speaker verification and identification employs voiceprints whose privacy 
and
   integrity must be maintained. While strictly speaking out of scope
   of the protocol itself, such considerations will be carefully
   considered and accommodated during protocol design, and will be
   called out as part of the applicability statement accompanying the
   protocol specification(s)."

> Other comments and thoughts outside the sections:
>
> 1. Does SPEECHSC need to address speech transcoding and rate
> conversions?
>
Good question. What do others think? My inclination is to put these on the 
list of things to think about after finishing the stuff on our plate at the 
moment. On consideration that might mitigate against trying to deal with 
these in speechsc is that speecsc is client-server whereas these two 
application are generally peer-to-peer. Viewed from another perspective, 
TTS/ASR/SR all send results back to the source of the input stream, whereas 
transcoding and rate adaptation take input from A and send it to B. This is 
an absolute though, as I could easily envision a service for 
hearing-impaired users which accomplishes this using speechsc machinery.

> 2. SPEECHSC MUST aware of distributed environment OA&M.
>
Other than a MIB, what do you have in mind? Note to chairs and ADs: perhaps 
we need to add milestone to produce a MIB for the protocol. In general the 
IETF does not do OA&M standards.

> 3. Support of new generation of smart communication devices, such
> as networked PDAs and smart phones. Speech, GUI and other user
> interface interactions need to be addressed in SPEECHSC to support
> multimodality.
>
Agree. If you can come up with concrete technical requirements derived for 
the need to support such things, we'll be very happy to add them!

> =========================================================================
> ===== Qiru Zhou
> (http://www.multimedia.bell-labs.com) Dialogue Systems Research
> Department,   Bell Laboratories, Lucent Technologies 600 Mountain Avenue,
> 2D428, Murray Hill, NJ 07974, USA
> tel +1 908 582 4562  | fax +1 908 582 7308  |
> [email-masked]
> =========================================================================
> =====

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

---

From: Qiru Zhou <[email-masked]>
Date: Fri, 20 Sep 2002 12:48:24 -0400

Sorry for resubmit this comments. It was bounced back due to different
e-mail reply address was used.

-- QZ

Hi, speechsc WG,

-- Qiru

1.   Abstract 

Suggestion:

change
to

3.   Introduction 

Suggestioin:

4.   SPEECHSC Framework 

5.   General Requirements 

Simultaneous or parallel are proper words here. It is application
dependent. I suggest change “5.6 Simultaneous services” to
“Media stream multiprocessing” and remove “in parallel.”

6.   TTS Requirements 
Suggest change  “to playback text as voice in an RTP stream.” To
“to synthesis text as speech in a packetized audio stream.”

“reading” is not a good word to describe TTS synthesis.
“synthesis” is more accurate. Also “playback” or “output”
are acceptable.

What is the definition of “document type of the text to
be processed” here? The document encoding, format, or language?

I am not sure why a TTS server needs "VCR Controls" functions.
Is this refer to the audio stream already produced by a TTS
server, Or the text before input to a TTS server. I don't
know how do you specify “time mark” accurately on the input
text. If the text is already produced by TTS, it seems to be
more logical to use an audio player to provide “VCR” or
tape player functions. These functions can be used for other
audio source as well. It is more complicate and impractical
to implement the “VCR” functions redundantly.

7.   ASR Requirements 

Reference [15] means: “The ASR Server MUST support the VoiceXML
Speech grammar specification for speech recognition [15].” Is
XML specification means that we only want to support XML format
of SRGS, not ABNF?

“capture the input media stream” is not a function of an
ASR server. It should be achieved by a audio recorder and
media database support. “later analysis and tuning” are
functions outside of a runtime ASR engine.
“grammar sharing” is a speech engine implementation and performance issue
which may not be necessary to specify in SPEECHSC. Also a VoiceXML
compliant SR engine need to support rule import/export, multi-grammar
in session as well.

9.   Dual-Mode Requirements
It is clearer to say “full duplex speech processing requirements”,
instead of “dual-mode”.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Comments to the list, as usual. Thanks.
==============================================================================
Qiru Zhou                                (
http://www.multimedia.bell-labs.com)
Dialogue Systems Research Department,   Bell Laboratories, Lucent
Technologies
600 Mountain Avenue, 2D428, Murray Hill, NJ 07974, USA 
tel +1 908 582 4562  | fax +1 908 582 7308  |
[email-masked]

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