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

From: "Garland Sharratt" <[email-masked]>
Date: Wed, 5 May 2004 09:24:55 -0700

I agree with Eric that we don't want MRCPv2 to expand too far in scope.
There are many media server languages already available, and making MRCPv2
into another one would not be a good thing.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Sarvi Shanmugham
Sent: Thursday, January 29, 2004 12:06
To: Eric Burger
Cc: SPEECHSC
Subject: Re: [Speechsc] RE: Scope of MRCPv2

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

Eric Burger wrote:

>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

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