Subject: Re: [MEDIACTRL] recording requirements: use case

From: "Eric Burger" <[email-masked]>
Date: Wed, 1 Aug 2007 05:06:12 -0700

Recording for most anything I think is covered.

The functionality described below feels like it is way out of scope (opinion as contributor, not as chair). Speech services, like ASR, are purely an internal matter to the media server. See MRCPv2 (speechsc).

I would also offer (now as chair) that any media server doing database dips or executing application logic is way beyond the definition of a media server and well beyond the scope of this group.

--
Sent from my wireless e-mail device. Sorry if terse.  We all need lemonade: see <http://www.standardstrack.com/ietf/lemonade> for what lemonade is.

-----Original Message-----
From: Haluska, John J <[email-masked]>
To: [email-masked] <[email-masked]>
Sent: Tue Jul 31 16:42:18 2007
Subject: [MEDIACTRL] recording requirements: use case

Hi all

I just wanted to clarify whether the requirements document as stands supports a particular use case. I asked the question last week in Chicago, but on looking at the requirements again, I’m not convinced that the “roll call” functionality (REQ-MCP-30 ?) actually covers this. So maybe it’s best if I give more details. 

Initially I was thinking that this would be covered by the Burke draft, and that might still be the best match. But, this use case will also need MRB functionality, so I think the MEDIACTRL mechanism would be preferable.

In this use case the user is played an announcement, and is prompted to give spoken input (e.g. a name to be looked up in a directory, etc).

The spoken input is stored.

The MS goes off to a speech recognition engine, etc, and retrieves some data (e.g. DB lookup) corresponding to the spoken input, or fails.

The MS then needs to return the following to the AS:

1. The pass/fail status of the speech recognition/data lookup operation

2. The data (or pointer to the same) returned by the lookup (only applicable on success)

3. A pointer to the file where the spoken request is stored (only required on failure). 

If the speech recognition failed, the MS may be asked to play back the file containing the spoken input to a stream. E.g. played back to a human attendant who would perform a manual lookup because the speech recognition failed.

I’d break these recording requirements into:

-Recording a short clip as part of a speech recognition request (versus conference/IVR, unless this can be considered as an IVR case)

-Accept parameters pertaining to the recording (e.g. preferred codecs, time compression, etc)

-Return a reference to that recording.

-Retain the recording for some period of time

-Accept a command to play back the explicitly referenced recording as an announcement onto a stream

-Delete the recording 1. on command (e.g. issued in conjunction with the playback request), 2. after some specified time (perhaps specified in the request)

And the other requirement:

-Return some arbitrary data (perhaps a pointer), such as the result of some operation based on speech recognition, to the AS.

 

A related, but much simpler use case exists, where a short spoken input is recorded and then requested to be played back again over a different stream.

 

Are the current requirements intended to cover such a use case? If not, should/could they?

Or is this best covered by the Burke draft?

Thanks

John Haluska

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "Haluska, John J" <[email-masked]>
Date: Wed, 1 Aug 2007 08:59:55 -0400

Hi Eric

Clearly the interfaces between MS and the ASR is out of scope.

I could break the use case into the following functions:

1. AS asks MS to prompt and record. Input is an announcement identifier.
Output from MS would be status and a reference to the recording (on
success).

2. AS asks MS to perform ASR. Input would include some identifier for
the specific ASR operation required, and a reference to the recording.
Outputs back from the MS would include pass/fail status, and data (or
reference) on success.

3. AS asks MS to play the recording onto an RTP stream. Input would be
reference to the recording, and some identifier for the stream. Output
would be status. Also, there needs to be a way to delete the recording
at some point.

Since 1. and 3. are pretty basic recording/playback requirements, it
sounds like they could be in scope. Is this correct?

What about 2. ? This is just between the AS and MS - I was not thinking
that any interface between the MS and ASR, etc is in scope for this
working group. This just refers to the capability for the AS to ask the
MS to do this, and to get data back.

Thanks,

John

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: Wednesday, August 01, 2007 8:06 AM
To: Haluska, John J; [email-masked]
Subject: Re: [MEDIACTRL] recording requirements: use case

The functionality described below feels like it is way out of scope
(opinion as contributor, not as chair). Speech services, like ASR, are
purely an internal matter to the media server. See MRCPv2 (speechsc).

I would also offer (now as chair) that any media server doing database
dips or executing application logic is way beyond the definition of a
media server and well beyond the scope of this group.

--
Sent from my wireless e-mail device. Sorry if terse.  We all need
lemonade: see <http://www.standardstrack.com/ietf/lemonade> for what
lemonade is.

-----Original Message-----
From: Haluska, John J <[email-masked]>
To: [email-masked] <[email-masked]>
Sent: Tue Jul 31 16:42:18 2007
Subject: [MEDIACTRL] recording requirements: use case

Hi all

I just wanted to clarify whether the requirements document as stands
supports a particular use case. I asked the question last week in
Chicago, but on looking at the requirements again, I'm not convinced
that the "roll call" functionality (REQ-MCP-30 ?) actually covers this.
So maybe it's best if I give more details. 

Initially I was thinking that this would be covered by the Burke draft,
and that might still be the best match. But, this use case will also
need MRB functionality, so I think the MEDIACTRL mechanism would be
preferable.

In this use case the user is played an announcement, and is prompted to
give spoken input (e.g. a name to be looked up in a directory, etc).

The MS goes off to a speech recognition engine, etc, and retrieves some
data (e.g. DB lookup) corresponding to the spoken input, or fails.

2. The data (or pointer to the same) returned by the lookup (only
applicable on success)

3. A pointer to the file where the spoken request is stored (only
required on failure). 

If the speech recognition failed, the MS may be asked to play back the
file containing the spoken input to a stream. E.g. played back to a
human attendant who would perform a manual lookup because the speech
recognition failed.

I'd break these recording requirements into:

-Recording a short clip as part of a speech recognition request (versus
conference/IVR, unless this can be considered as an IVR case)

-Accept parameters pertaining to the recording (e.g. preferred codecs,
time compression, etc)

-Accept a command to play back the explicitly referenced recording as an
announcement onto a stream

-Delete the recording 1. on command (e.g. issued in conjunction with the
playback request), 2. after some specified time (perhaps specified in
the request)

-Return some arbitrary data (perhaps a pointer), such as the result of
some operation based on speech recognition, to the AS.

 

A related, but much simpler use case exists, where a short spoken input
is recorded and then requested to be played back again over a different
stream.

 

Are the current requirements intended to cover such a use case? If not,
should/could they?

 

Thanks

John Haluska

Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

---

From: RahulSrivastava 71616 <[email-masked]>
Date: Wed, 01 Aug 2007 23:07:14 +0800

Hi All,

This is a similar question from John.
Some media servers offer various interfaces to store recording viz nfs,ftp,http to name a few with each is its own set of peculiar naming conventions.
This leaves a very difficult design issue for AS to have a common message between MS and AS irrespective of protocol between AS and MS since most of the time (or some times depends how you design the application), especially in recording, AS needs to pass the location of destination record file to MS.
I am not too sure how we'll address this inside this group.
Please throw some light on this. 

Rahul   

******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
 *****************************************************************************************

----- Original Message -----
From: "Haluska, John J" <[email-masked]>
Date: Wednesday, August 1, 2007 8:59 pm
Subject: RE: [MEDIACTRL] recording requirements: use case

> 1. AS asks MS to prompt and record. Input is an announcement 
> identifier.Output from MS would be status and a reference to the 
> recording (on
> success).
> 
> 
> What about 2. ? This is just between the AS and MS - I was not 
> thinkingthat any interface between the MS and ASR, etc is in scope 
> for this
> that the "roll call" functionality (REQ-MCP-30 ?) actually covers 
> this.So maybe it's best if I give more details. 
> 
> 
> 
> Initially I was thinking that this would be covered by the Burke 
> draft,and that might still be the best match. But, this use case 
> will also
> The MS goes off to a speech recognition engine, etc, and retrieves 
> somedata (e.g. DB lookup) corresponding to the spoken input, or fails.
> 
> 
> 
> -Recording a short clip as part of a speech recognition request 
> (versusconference/IVR, unless this can be considered as an IVR case)
> 
> A related, but much simpler use case exists, where a short spoken 
> inputis recorded and then requested to be played back again over a 
> differentstream.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Are the current requirements intended to cover such a use case? If 
> not,should/could they?
> 
> 
> 
> Notice:  This email message, together with any attachments, may 
> containinformation  of  BEA Systems,  Inc.,  its subsidiaries  and 
> affiliated
> entities,  that may be confidential,  proprietary,  copyrighted  
> and/orlegally privileged, and is intended solely for the use of 
> the individual
> or entity named in this message. If you are not the intended 
> recipient,and have received this message in error, please 
> immediately return this

---

From: "Haluska, John J" <[email-masked]>
Date: Wed, 1 Aug 2007 11:50:10 -0400

Rahul

I think you have an important question, but I think this is much
different from mine. Mine is focused only on the AS-MS control protocol,
not on other interfaces to the MS, but this may not have come across
clearly. My question dealt with:

1. recording requirements, which do appear to be in scope.

2. Whether the ability to pass information required by ASR-type
functionality is in scope. 

Maybe another way to look at this is to ask whether the AS requesting
the MS to perform ASR-type functionality can be considered part of IVR
functionality (the actual MS-ASR interactions are clearly out of scope),
since IVR is in scope. If so, then I think it could be addressed in an
IVR control package. I am not thinking that the requirements document
would need to list every possible function related to IVR. 

For your question, I think that it will be necessary to be able to
specify explicit URIs for stored information, and perhaps list the
schema we need to be able to signal. But this is probably for something
like the IVR control packages, not the requirements doc. 

John

-----Original Message-----
From: RahulSrivastava 71616 [mailto:[email-masked]] 
Sent: Wednesday, August 01, 2007 11:07 AM
To: Haluska, John J
Cc: Eric Burger; [email-masked]
Subject: Re: RE: [MEDIACTRL] recording requirements: use case

Hi All,

This is a similar question from John.
Some media servers offer various interfaces to store recording viz
nfs,ftp,http to name a few with each is its own set of peculiar naming
conventions.
This leaves a very difficult design issue for AS to have a common
message between MS and AS irrespective of protocol between AS and MS
since most of the time (or some times depends how you design the
application), especially in recording, AS needs to pass the location of
destination record file to MS.
I am not too sure how we'll address this inside this group.
Please throw some light on this. 

Rahul   

************************************************************************
******************
 This email and its attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure,
reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please
notify the sender by phone or email immediately and delete it!
 
************************************************************************
*****************

---

From: Diego B <[email-masked]>
Date: Wed, 01 Aug 2007 18:49:11 +0200

Hi;
I don't know if I understood your question right.
But my answer for your question is using a script.
The requirements document lists:

REQ-MCP-28 -  The AS shall be able to load one or more IVR script to
      the MS and receive the results.

So, using vxml, for example, you can perform 1, 2 and 3 

Regards
Diego B

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 1 Aug 2007 17:10:01 +0100

[Chris Boulton] So here is my take.  I see that basic IVR interactions
are most definitely in scope (for example, we are documenting in
http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-03
.txt).  We really need to then draw a line in the sand.  For advanced
IVR we have VoiceXML which is the king and its various mechanisms for
invocation (e.g. NETANN), which should include a MediaCtrl solution
(which we are documenting in
http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control-packa
ge-02.txt).

Chris.

Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Ubiquity Software Corporation plc, a company registered under the laws of England and Wales, Registration 2719723, registered offices at Eastern Business Park, Building 3, Wern Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales, United Kingdom.

---

From: "MUNSON, GARY A (GARY A)" <[email-masked]>
Date: Wed, 1 Aug 2007 12:59:14 -0400

Hi Eric et al,

Regarding the latter from the email below: 

"I would also offer (now as chair) that any media server doing database
dips or executing application logic is way beyond the definition of a
media server and well beyond the scope of this group."

I don't want to get into a religious debate, and I understand what the
basic traditional view of Media Server is, but in practice it can be
useful to think of a media server doing the kinds of things mentioned,
such as application logic or database dips. Some of us hit that
territory in another forum when considering how to model the unit of
functionality of an agent workstation in a VoIP world. **But** from the
point of view of an AS or MRB, they would still see such a media server
in the traditional sense. At most, there may be an impact at the data
level - e.g., specific information that needs to be passed between AS
and MS, or specific MS attributes for MRB purposes.

Now, somebody could go way overboard and imagine a media server that,
e.g., violates the AS-MS control relationship. That somebody wouldn't be
me.

cheers,

Gary

-----Original Message-----
From: Haluska, John J <[email-masked]>
To: [email-masked] <[email-masked]>
Sent: Tue Jul 31 16:42:18 2007
Subject: [MEDIACTRL] recording requirements: use case

Hi all

 

 

 

 

 

 

Thanks

John Haluska

---

From: "Haluska, John J" <[email-masked]>
Date: Wed, 1 Aug 2007 13:48:27 -0400

Chris

Thanks for the input. Couple of follow up questions if you don't mind:

A. From looking at the Basic IVR control package, I can see that 1.(play
an announcement and record the spoken request)  and 3.(play out the
stored spoken request on another stream) are pretty clearly covered by
"promptandrecord", and "playannouncement", respectively. Do you agree?

B. Do you see 2. (perform ASR/perform a lookup on the spoken request,
and return the pass/fail status and associated data) as being covered by
the Advanced IVR control package? An example of this is to ask the MS to
match a spoken name to an entry in a directory, and return back data
from that entry.

Please don't mistake my questions for insistence that the
recording/playback and ASR functionality be directly addressed in the
requirements document. As long as they're covered somewhere, I think I'm
ok.

Thanks,

John

-----Original Message-----
From: Chris Boulton [mailto:[email-masked]] 
Sent: Wednesday, August 01, 2007 12:10 PM
To: Haluska, John J; RahulSrivastava 71616
Cc: [email-masked]
Subject: RE: RE: [MEDIACTRL] recording requirements: use case

Chris.

Information contained in this e-mail and any attachments are intended
for the use of the addressee only, and may contain confidential
information of Ubiquity Software Corporation. All unauthorized use,
disclosure or distribution is strictly prohibited.  If you are not the
addressee, please notify the sender immediately and destroy all copies
of this email. Ubiquity Software Corporation plc, a company registered
under the laws of England and Wales, Registration 2719723, registered
offices at Eastern Business Park, Building 3, Wern Fawr Lane, St.
Mellons, Cardiff CF3 5EA, Wales, United Kingdom.

---

From: Eric Burger <[email-masked]>
Date: Wed, 01 Aug 2007 14:51:42 -0400

I don¹t see this scenario as in scope for MEDIACTRL.  This is precisely the
SPEECHSC use case.

---

From: Eric Burger <[email-masked]>
Date: Wed, 01 Aug 2007 15:33:04 -0400

If the media server uses the AS-MS protocol, which has no facility for data
base dips, but the media server does data base dips in its execution of the
protocol requests, that is great.  I could imagine (in our never ending QoS
debates) where a publicly-addressable MS does its own ACL administration of
requests against a DIAMETER data base.

The point here is that procedure is 100% OUTSIDE THE SCOPE of the AS-MS
protocol.  We do not care.  You can do whatever you want, so long as you do
not expose it.

---

From: Eric Burger <[email-masked]>
Date: Wed, 01 Aug 2007 15:30:12 -0400

It is always a URI.  URI's can be file (NFS), ftp, or http schemes.  That
is, the application is most likely going to know the storage mechanism if it
is going to ask explicitly for a recording.

Note that VoiceXML does not have this problem.  VoiceXML is always http.

On 8/1/07 10:07 AM, "RahulSrivastava 71616" <[email-masked]> wrote:

> This leaves a very difficult design issue for AS to have a common message
> between MS and AS irrespective of protocol between AS and MS since most of the
> time (or some times depends how you design the application), especially in
> recording, AS needs to pass the location of destination record file to MS.
>  This email and its attachments contain confidential information from HUAWEI,
> which is intended only for the person or entity whose address is listed above.
> Any use of the information contained herein in any way (including, but not
> limited to, total or partial disclosure, reproduction, or dissemination) by
> persons other than the intended recipient(s) is prohibited. If you receive
> this e-mail in error, please notify the sender by phone or email immediately
> and delete it!
>

---

From: "MUNSON, GARY A (GARY A)" <[email-masked]>
Date: Wed, 1 Aug 2007 17:03:19 -0400

Agreed, thank you. Except I'd rather not talk about QoS.  :-)

Gary

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: Wednesday, August 01, 2007 3:33 PM
To: MUNSON, GARY A (GARY A)
Cc: [email-masked]
Subject: Re: [MEDIACTRL] RE: what is a media server

If the media server uses the AS-MS protocol, which has no facility for
data
base dips, but the media server does data base dips in its execution of
the
protocol requests, that is great.  I could imagine (in our never ending
QoS
debates) where a publicly-addressable MS does its own ACL administration
of
requests against a DIAMETER data base.

The point here is that procedure is 100% OUTSIDE THE SCOPE of the AS-MS
protocol.  We do not care.  You can do whatever you want, so long as you
do
not expose it.

> media server and well beyond the scope of this group.
this.
> Initially I was thinking that this would be covered by the Burke
draft,
> The MS goes off to a speech recognition engine, etc, and retrieves
some
> -Recording a short clip as part of a speech recognition request
(versus
> A related, but much simpler use case exists, where a short spoken
input
> Are the current requirements intended to cover such a use case? If
not,
> Notice:  This email message, together with any attachments, may
contain
> entities,  that may be confidential,  proprietary,  copyrighted
and/or
> or entity named in this message. If you are not the intended
recipient,

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 2 Aug 2007 10:02:17 +0100

[Chris Boulton] Always a pleasure :-).

[Chris Boulton] Agreed.  The latter are just for convenience.

[Chris Boulton] Advanced IVR package?  At the moment we only have the
basic IVR package and it is the intention that for advanced IVR you
wither use the VXML control package or some other popular mechanism.

Chris.

---

From: "Haluska, John J" <[email-masked]>
Date: Thu, 2 Aug 2007 07:53:41 -0400

Chris

Sorry, I was referring to draft-boulton-ivr-vxml-control-package. Would
you agree that this would work for the ASR case?

John

-----Original Message-----
From: Chris Boulton [mailto:[email-masked]] 
Sent: Thursday, August 02, 2007 5:02 AM
To: Haluska, John J; RahulSrivastava 71616
Cc: [email-masked]
Subject: RE: RE: [MEDIACTRL] recording requirements: use case

Chris.