Subject: RE: [Speechsc] RE: Scope of MRCPv2

From: "Eric Burger" <[email-masked]>
Date: Thu, 29 Jan 2004 11:16:55 -0500

Detecting DTMF and playing audio works SO LONG as it is a side-effect, and not a goal.  I would not want to see MRCPv2 start handling, for example, fax, transcoding, recording for playback purposes, etc.

-----Original Message-----
From: Sarvi Shanmugham [mailto:[email-masked]]
Sent: Wednesday, January 28, 2004 12:53 PM
To: Eric Burger
Cc: SPEECHSC
Subject: Re: [Speechsc] RE: Scope of MRCPv2

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

Eric Burger wrote:

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

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

---

From: Sarvi Shanmugham <[email-masked]>
Date: Thu, 29 Jan 2004 12:05:48 -0800

Though DTMF was not the primary goal,  it is supported through DTMF only 
headers like Dtmf-Term-Char etc. that were added to support VXML 
documents with DTMF only grammars.
 I don't believe we have done anything special for audio play back, its 
just a synthesizer with limited capabilities.
There is a need for recording as part of MRCP that has been voiced 
earlier and agreed on during the last meeting. The MRCPv1 extension 
proposes a Recording capability where the audio can be played back. A 
few reasons why recording functionality is being added is that in some 
cases,
    1. we need functionality such as audio end-pointing(related to 
recognizers) to start and stop recording.
    2. we may need to co-ordinate with DTMF recognition and play back 
for starting and stoping recordings.
And again like you say, it was added mostly because there were some 
requirements related to recognizers and synthesizers. But I believe we 
should limit its use  if some one wants to use it as plain recorder for 
recording voice mail or something.

Fax and Transcoding I agree are not it scope.

Sarvi