Subject: [Speechsc] RE: Scope of MRCPv2

From: "Eric Burger" <[email-masked]>
Date: Wed, 28 Jan 2004 08:15:47 -0500

I would call your example WAY out of scope.

Existing device control choices are J.162 (somewhat documented in RFC3435) and H.248.1 (standardized in RFC3525).

Existing application-level choices are VoiceXML (netann) and MSCML (documented in mscml).

Do we really need more than that? :-)

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Sunday, January 18, 2004 11:16 AM
> To: SPEECHSC; Eric Burger; Dave Oran
> Subject: Scope of MRCPv2
> 
> 
> 
> I'm trying to figure out the scope of what I should or should 
> not use MRCPv2
> for so that I can try and decide what might be missing from it.
> 
> Consider the use case of an IVR build with a separated media 
> device and
> controller. The media device plays audio prompts, reports 
> DTMF input up to
> the controller, can stop audio playback when there is DTMF 
> input, and can
> record audio it receives to files for later playback. It does 
> not do any
> TTS, ASR, or speaker verification.
> 
> Is this a use case we want to solve with MRCPv2 or should a different
> protocol be used for this?
> 
> Thanks, Cullen
> 
> 
> 

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

---

From: Sarvi Shanmugham <[email-masked]>
Date: Wed, 28 Jan 2004 09:52:57 -0800

I would tend to disagree here.

The speechrecog resource, in its simplest form can be a DTMF recognizer 
without any changes to the MRCPv2 protocol. Unless ofcourse the question 
was about reporting individual digits as opposed to matching DTMF 
grammars, in which case i agree with you.
The speechsynth resource in its simplest form is an audioplayer(or one 
that can do concatenated prompts at the next level), without any changes 
to the MRCPv2 protocol.
The MRCPv1 extension proposal already has recording support, which 
doesn't seem different from what is requested here.

So I tend to think that the scenario being requested can be addressed 
with spec as is and should meet its needs.
The client may at various times choose to resources of varying levels of 
capabilities such as audioplayer, simplesynth(poor man's TTS) and 
advanced synth or DTMF only recog and speechrecog. The usage semantics 
are thre same and we shouldn't require the client to use different 
protocols for each.

Sarvi