[MEDIACTRL] RE: MRB - MS Publish Interface

["Krishna Prasad Kalluri (TN/EAB)" <[e-mail]>]

I receive the mail in the digest mode so I don't have the exact mail for which I want to respond. I would like to reply to the mail with subject MRB - MS Publish Interface. I am also pasting the original mail here. Sorry if there is any inconvenience. 

I would like to brain storm and collect a list of information that would be useful.  I'm going to throw a few topics in the bucket to get us rolling.

 

-          Active RTP sessions (including codec information)

o        For example, 10 G711 RTP sessions, 3 H.264 sessions.

-          Non Active sessions - so sessions available on this MS (based on codec's supported)

o        For example, 80 G711 RTP session, 120 G729 sessions, 30 H.264 sessions.

-          MS Uptime

-          Codecs/media supported (could just be bundled with above - 'Non Active Sessions').

REPLY

******

 

1) The Active/Non Active session gives any information about the type of session. i.e. Announcement session or conference session etc..

 

If a Media server publishes 80 non active G711 RTP sessions means Application server can use this for a conference session with 80 participants?

 

In general from the Media Server resource handling point of view there will be different restrictions for announcements and conferences. May be a Media Server can support X number of participants per conference. 

Eg: A media server can support 25 Participants per Conference and may be maximum 10 ongoing conferences. 

 

So I would like to see resources available for different Media functionality.

 

2) How frequently this publish information will be sent from the Media Server to AS? 

- Up on query from AS to MS or

- As soon as some change of state in MS which triggers the MS to publish the information. 

 

3) Some more information in PUBLISH which I can think of now. I don't know may be some of the information in the below list can be obtained by other means?

 

*	File formats supported for announcement. E.g.: MP3, WAW etc... May be this information is enough to determine announcement format supported i.e. audio or video
*	Maximum duration for an announcement. Media servers can have restrictions on memory to play the announcements for very long durations.
*	Variable announcements. Where the substitution variable can be time, date, cost etc.
*	DTMF detection and generation support. 
*	Types of mixing (conference supported) audio, video
*	Supported tone types in the Media Server. Different countries may have different characteristics for the same tone. So the tone characteristics can be configured in the media server or can be downloaded. Capability to play the tone in both directions may be required for conferencing applications. E.g. playing a tone when a new participant joins in the conference. The tone needs to be played towards the existing participants and also towards the new participant.


________________________________

Från: [e-mail] [mailto:[e-mail]]
Skickat: to 2007-08-02 18:00
Till: [e-mail]
Ämne: MEDIACTRL Digest, Vol 8, Issue 2



Send MEDIACTRL mailing list submissions to
        [e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
        https://www1.ietf.org/mailman/listinfo/mediactrl
or, via email, send a message with subject or body 'help' to
        [e-mail]

You can reach the person managing the list at
        [e-mail]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of MEDIACTRL digest..."


Today's Topics:

   1. RE: RE: [MEDIACTRL] recording requirements: use case
      (Chris Boulton)
   2.  RE: what is a media server (MUNSON, GARY A (GARY A))
   3.  Frameworks, Frameworks, and More Frameworks (Eric Burger)
   4. RE: RE: [MEDIACTRL] recording requirements: use case
      (Haluska, John J)
   5. Re:  recording requirements: use case (Eric Burger)
   6. Re:  RE: what is a media server (Eric Burger)
   7. Re:  recording requirements: use case (Eric Burger)
   8. RE:  RE: what is a media server (MUNSON, GARY A (GARY A))
   9. RE: RE: [MEDIACTRL] recording requirements: use case
      (Chris Boulton)
  10.  MRB - MS Publish Interface (Chris Boulton)
  11.  MRB - MS Query Interface (Chris Boulton)
  12. RE: RE: [MEDIACTRL] recording requirements: use case
      (Haluska, John J)
  13. Re:  Frameworks, Frameworks, and More Frameworks (Lorenzo Miniero)
  14. Re:  MRB - MS Publish Interface (Diego B)
  15. RE:  MRB - MS Query Interface (Haluska, John J)
  16. RE:  MRB - MS Query Interface (Chris Boulton)
  17. Re:  Frameworks, Frameworks, and More Frameworks
      (Simon Pietro Romano)
  18. RE:  Frameworks, Frameworks, and More Frameworks (Mary Barnes)
  19. RE:  MRB - MS Query Interface (Haluska, John J)


----------------------------------------------------------------------

Message: 1
Date: Wed, 1 Aug 2007 17:10:01 +0100
From: "Chris Boulton" <[e-mail]>
Subject: RE: RE: [MEDIACTRL] recording requirements: use case
To: "Haluska, John J" <[e-mail]>, "RahulSrivastava
        71616" <[e-mail]>
Cc: [e-mail]
Message-ID:
        <[e-mail]>
Content-Type: text/plain;       charset="us-ascii"

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.

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





------------------------------

Message: 2
Date: Wed, 1 Aug 2007 12:59:14 -0400
From: "MUNSON, GARY A (GARY A)" <[e-mail]>
Subject: [MEDIACTRL] RE: what is a media server
To: <[e-mail]>
Message-ID:
        <[e-mail]>
Content-Type: text/plain;       charset="us-ascii"

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: Eric Burger [mailto:[e-mail]]
Sent: Wednesday, August 01, 2007 8:06 AM
To: [e-mail]; [e-mail]
Subject: Re: [MEDIACTRL] recording requirements: use case

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 <[e-mail]>
To: [e-mail] <[e-mail]>
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
[e-mail]
https://www1.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl




------------------------------

Message: 3
Date: Wed, 01 Aug 2007 09:51:27 -0500
From: Eric Burger <[e-mail]>
Subject: [MEDIACTRL] Frameworks, Frameworks, and More Frameworks
To: <[e-mail]>, Tim Melanchuk <[e-mail]>,
        Chris Boulton <[e-mail]>
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII

First, a call for consensus.  We would like to confirm the sentiment in the
room in Chicago, that both of the following documents will be the basis for
work group items.

draft-melanchuk-mediactrl-framework-00 is
An Architectural Framework for Media Server Control

draft-boulton-sip-control-framework-05 is
A Control Framework for the Session Initiation Protocol (SIP)

[ ] No Objection
[ ] Object (Must explain why)


As chair, I will fall on my sword here.  Since the beginning of the Bar
BOFs, we tend to have multiple documents with different names talking about
the same thing (anyone remember the Requirements and Framework documents?).
We have had multiple documents with similar names talking about different
things.  Well, it is time to disambiguate this latter case.

To reduce confusion, the Architectural Framework will be called:
draft-ietf-mediactrl-architecture
and the Control Framework will be called:
draft-ietf-mediactrl-sip-control-framework

Editors, in the To: field, make a note of this


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.




------------------------------

Message: 4
Date: Wed, 1 Aug 2007 13:48:27 -0400
From: "Haluska, John J" <[e-mail]>
Subject: RE: RE: [MEDIACTRL] recording requirements: use case
To: "Chris Boulton" <[e-mail]>,    "RahulSrivastava 71616"
        <[e-mail]>
Cc: [e-mail]
Message-ID:
        <[e-mail]>
       
Content-Type: text/plain;       charset="us-ascii"

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:[e-mail]]
Sent: Wednesday, August 01, 2007 12:10 PM
To: Haluska, John J; RahulSrivastava 71616
Cc: [e-mail]
Subject: RE: RE: [MEDIACTRL] recording requirements: use case

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.

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





------------------------------

Message: 5
Date: Wed, 01 Aug 2007 14:51:42 -0400
From: Eric Burger <[e-mail]>
Subject: Re: [MEDIACTRL] recording requirements: use case
To: "Haluska, John J" <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="iso-8859-1"

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


On 8/1/07 7:59 AM, "Haluska, John J" <[e-mail]> wrote:

> 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:[e-mail]]
> Sent: Wednesday, August 01, 2007 8:06 AM
> To: Haluska, John J; [e-mail]
> Subject: Re: [MEDIACTRL] recording requirements: use case
>
> 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 <[e-mail]>
> To: [e-mail] <[e-mail]>
> 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.
>



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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www1.ietf.org/pipermail/mediactrl/attachments/20070801/cbe28da7/attachment-0001.html

------------------------------

Message: 6
Date: Wed, 01 Aug 2007 15:33:04 -0400
From: Eric Burger <[e-mail]>
Subject: Re: [MEDIACTRL] RE: what is a media server
To: Gary Munson <[e-mail]>
Cc: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII

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.


On 8/1/07 11:59 AM, "MUNSON, GARY A (GARY A)" <[e-mail]> wrote:

> 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: Eric Burger [mailto:[e-mail]]
> Sent: Wednesday, August 01, 2007 8:06 AM
> To: [e-mail]; [e-mail]
> Subject: Re: [MEDIACTRL] recording requirements: use case
>
> 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 <[e-mail]>
> To: [e-mail] <[e-mail]>
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl
>
>
> _______________________________________________
> MEDIACTRL mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl
>



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.




------------------------------

Message: 7
Date: Wed, 01 Aug 2007 15:30:12 -0400
From: Eric Burger <[e-mail]>
Subject: Re: [MEDIACTRL] recording requirements: use case
To: RahulSrivastava 71616 <[e-mail]>
Cc: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII

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" <[e-mail]> wrote:

> 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" <[e-mail]>
> Date: Wednesday, August 1, 2007 8:59 pm
> Subject: RE: [MEDIACTRL] recording requirements: use case
>
>> 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
>> thinkingthat 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:[e-mail]]
>> Sent: Wednesday, August 01, 2007 8:06 AM
>> To: Haluska, John J; [e-mail]
>> Subject: Re: [MEDIACTRL] recording requirements: use case
>>
>> 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 <[e-mail]>
>> To: [e-mail] <[e-mail]>
>> 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
>> somedata (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
>> (versusconference/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
>> 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?
>>
>>
>>
>> Or is this best covered by the Burke draft?
>>
>>
>>
>>
>>
>>
>>
>> Thanks
>>
>>
>>
>> John Haluska
>>
>>
>>
>>
>> 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
>> by email and then delete it.
>>
>>
>> _______________________________________________
>> MEDIACTRL mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/mediactrl
>> Supplemental Web Site:
>> http://www.standardstrack.com/ietf/mediactrl
>>
>



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.




------------------------------

Message: 8
Date: Wed, 1 Aug 2007 17:03:19 -0400
From: "MUNSON, GARY A (GARY A)" <[e-mail]>
Subject: RE: [MEDIACTRL] RE: what is a media server
To: "Eric Burger" <[e-mail]>
Cc: [e-mail]
Message-ID:
        <[e-mail]>
Content-Type: text/plain;       charset="us-ascii"

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

Gary

-----Original Message-----
From: Eric Burger [mailto:[e-mail]]
Sent: Wednesday, August 01, 2007 3:33 PM
To: MUNSON, GARY A (GARY A)
Cc: [e-mail]
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.


On 8/1/07 11:59 AM, "MUNSON, GARY A (GARY A)" <[e-mail]> wrote:

> 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: Eric Burger [mailto:[e-mail]]
> Sent: Wednesday, August 01, 2007 8:06 AM
> To: [e-mail]; [e-mail]
> Subject: Re: [MEDIACTRL] recording requirements: use case
>
> 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 <[e-mail]>
> To: [e-mail] <[e-mail]>
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl
>
>
> _______________________________________________
> MEDIACTRL mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl
>



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.




------------------------------

Message: 9
Date: Thu, 2 Aug 2007 10:02:17 +0100
From: "Chris Boulton" <[e-mail]>
Subject: RE: RE: [MEDIACTRL] recording requirements: use case
To: "Haluska, John J" <[e-mail]>, "RahulSrivastava
        71616" <[e-mail]>
Cc: [e-mail]
Message-ID:
        <[e-mail]>
Content-Type: text/plain;       charset="us-ascii"

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

[Chris Boulton] Always a pleasure :-).

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?

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

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.

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





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.





------------------------------

Message: 10
Date: Thu, 2 Aug 2007 10:43:29 +0100
From: "Chris Boulton" <[e-mail]>
Subject: [MEDIACTRL] MRB - MS Publish Interface
To: <[e-mail]>
Message-ID:
        <[e-mail]>
Content-Type: text/plain; charset="us-ascii"

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 15375 bytes
Desc: image001.jpg
Url : http://www1.ietf.org/pipermail/mediactrl/attachments/20070802/c56da9a5/attachment-0001.jpe

------------------------------

Message: 11
Date: Thu, 2 Aug 2007 11:04:13 +0100
From: "Chris Boulton" <[e-mail]>
Subject: [MEDIACTRL] MRB - MS Query Interface
To: <[e-mail]>
Message-ID:
        <[e-mail]>
Content-Type: text/plain; charset="us-ascii"

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 15375 bytes
Desc: image001.jpg
Url : http://www1.ietf.org/pipermail/mediactrl/attachments/20070802/0af2aee8/attachment-0001.jpe

------------------------------

Message: 12
Date: Thu, 2 Aug 2007 07:53:41 -0400
From: "Haluska, John J" <[e-mail]>
Subject: RE: RE: [MEDIACTRL] recording requirements: use case
To: "Chris Boulton" <[e-mail]>,    "RahulSrivastava 71616"
        <[e-mail]>
Cc: [e-mail]
Message-ID:
        <[e-mail]>
       
Content-Type: text/plain;       charset="us-ascii"


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:[e-mail]]
Sent: Thursday, August 02, 2007 5:02 AM
To: Haluska, John J; RahulSrivastava 71616
Cc: [e-mail]
Subject: RE: RE: [MEDIACTRL] recording requirements: use case

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

[Chris Boulton] Always a pleasure :-).

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?

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

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.

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





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.





------------------------------

Message: 13
Date: Thu, 2 Aug 2007 14:50:48 +0200
From: Lorenzo Miniero <[e-mail]>
Subject: Re: [MEDIACTRL] Frameworks, Frameworks, and More Frameworks
To: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain;  charset="iso-8859-1"

Hi Eric,

No objection at all from me on both documents. I personally do believe that
Chris' framework document is an excellent way to deal with the MediaCtrl
protocol needs.

Lorenzo


On Wednesday 01 August 2007 16:51:27 Eric Burger wrote:
> First, a call for consensus.  We would like to confirm the sentiment in the
> room in Chicago, that both of the following documents will be the basis for
> work group items.
>
> draft-melanchuk-mediactrl-framework-00 is
> An Architectural Framework for Media Server Control
>
> draft-boulton-sip-control-framework-05 is
> A Control Framework for the Session Initiation Protocol (SIP)
>
> [ ] No Objection
> [ ] Object (Must explain why)
>
>
> As chair, I will fall on my sword here.  Since the beginning of the Bar
> BOFs, we tend to have multiple documents with different names talking about
> the same thing (anyone remember the Requirements and Framework documents?).
> We have had multiple documents with similar names talking about different
> things.  Well, it is time to disambiguate this latter case.
>
> To reduce confusion, the Architectural Framework will be called:
> draft-ietf-mediactrl-architecture
> and the Control Framework will be called:
> draft-ietf-mediactrl-sip-control-framework
>
> Editors, in the To: field, make a note of this
>
>
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl



--
Lorenzo Miniero, Junior Researcher
Dipartimento di Informatica e Sistemistica
Università degli Studi di Napoli "Federico II"
Via Claudio 21 -- 80125 Napoli (Italy)
Phone: [phone] - Fax: [phone]
Email: [e-mail]




------------------------------

Message: 14
Date: Thu, 02 Aug 2007 15:54:44 +0300
From: Diego B <[e-mail]>
Subject: Re: [MEDIACTRL] MRB - MS Publish Interface
To: Chris Boulton <[e-mail]>
Cc: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=windows-1252; format=flowed

Hi;
I will add some mixer capability information,
Like Active mixers:
4: (2 G711, 3 G729), (second mixer and the codecs), (third mixer), ...)

Now, on the non active mixers, I'm not sure how to calculate and express
this information.

Regards
Diego B


Chris Boulton wrote:
>
> Hi All,
>
> This is the first of two mails that I will be posting on the topic of
> the MRB's associated interfaces. The idea is to collect relevant high
> level information related to the interfaces to help form the basis of
> the next version of the draft. This mail specifically deals with the
> Media Server publishing interface, as detailed in the MRB draft
> (http://www.ietf.org/internet-drafts/draft-boulton-mediactrl-mrb-00.txt
> as (1) in the following diagram.
>
> I would like to brain storm and collect a list of information that
> would be useful. I'm going to throw a few topics in the bucket to get
> us rolling.
>
> - Active RTP sessions (including codec information)
>
> o For example, 10 G711 RTP sessions, 3 H.264 sessions.
>
> - Non Active sessions - so sessions available on this MS (based on
> codec's supported)
>
> o For example, 80 G711 RTP session, 120 G729 sessions, 30 H.264 sessions.
>
> - MS Uptime
>
> - Codecs/media supported (could just be bundled with above - 'Non
> Active Sessions').
>
> Your input is greatly appreciated (especially you MS guys).
>
> 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.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> MEDIACTRL mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl




------------------------------

Message: 15
Date: Thu, 2 Aug 2007 10:08:26 -0400
From: "Haluska, John J" <[e-mail]>
Subject: RE: [MEDIACTRL] MRB - MS Query Interface
To: "Chris Boulton" <[e-mail]>, <[e-mail]>
Message-ID:
        <[e-mail]>
       
Content-Type: text/plain; charset="us-ascii"

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 15375 bytes
Desc: image001.jpg
Url : http://www1.ietf.org/pipermail/mediactrl/attachments/20070802/e73f2e37/attachment-0001.jpe

------------------------------

Message: 16
Date: Thu, 2 Aug 2007 15:44:07 +0100
From: "Chris Boulton" <[e-mail]>
Subject: RE: [MEDIACTRL] MRB - MS Query Interface
To: "Haluska, John J" <[e-mail]>, <[e-mail]>
Message-ID:
        <[e-mail]>
Content-Type: text/plain; charset="us-ascii"

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 15375 bytes
Desc: image001.jpg
Url : http://www1.ietf.org/pipermail/mediactrl/attachments/20070802/d4d0004a/attachment-0001.jpe

------------------------------

Message: 17
Date: Thu,  2 Aug 2007 17:09:38 +0200
From: Simon Pietro Romano <[e-mail]>
Subject: Re: [MEDIACTRL] Frameworks, Frameworks, and More Frameworks
To: Eric Burger <[e-mail]>
Cc: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1

Dear Eric/all,

here is my 'sentiment'...

> First, a call for consensus.  We would like to confirm the sentiment in the
> room in Chicago, that both of the following documents will be the basis for
> work group items.
>
> draft-melanchuk-mediactrl-framework-00 is
> An Architectural Framework for Media Server Control
>
> draft-boulton-sip-control-framework-05 is
> A Control Framework for the Session Initiation Protocol (SIP)
>
[X] No Objection
[ ] Object (Must explain why)

Simon

--
                            _\\|//_
                            ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    Simon Pietro Romano
              Universita' di Napoli Federico II
                 Computer Science Department
        Phone: [phone] -- Fax: [phone]
                e-mail: [e-mail]

    <<Molti mi dicono che lo scoraggiamento è l'alibi degli
   idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                         oooO
   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                          \ (    (   )
                           \_)    ) /
                                 (_/

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.




------------------------------

Message: 18
Date: Thu, 2 Aug 2007 10:51:50 -0500
From: "Mary Barnes" <[e-mail]>
Subject: RE: [MEDIACTRL] Frameworks, Frameworks, and More Frameworks
To: "Eric Burger" <[e-mail]>, <[e-mail]>,      "Tim
        Melanchuk" <[e-mail]>,   "Chris Boulton"
        <[e-mail]>
Message-ID:
        <[e-mail]>
Content-Type: text/plain;       charset="us-ascii"

[X] No Objection

Mary.


-----Original Message-----
From: Eric Burger [mailto:[e-mail]]
Sent: Wednesday, August 01, 2007 9:51 AM
To: [e-mail]; Tim Melanchuk; Chris Boulton
Subject: [MEDIACTRL] Frameworks, Frameworks, and More Frameworks


First, a call for consensus.  We would like to confirm the sentiment in
the
room in Chicago, that both of the following documents will be the basis
for
work group items.

draft-melanchuk-mediactrl-framework-00 is
An Architectural Framework for Media Server Control

draft-boulton-sip-control-framework-05 is
A Control Framework for the Session Initiation Protocol (SIP)

[ ] No Objection
[ ] Object (Must explain why)


As chair, I will fall on my sword here.  Since the beginning of the Bar
BOFs, we tend to have multiple documents with different names talking
about
the same thing (anyone remember the Requirements and Framework
documents?).
We have had multiple documents with similar names talking about
different
things.  Well, it is time to disambiguate this latter case.

To reduce confusion, the Architectural Framework will be called:
draft-ietf-mediactrl-architecture
and the Control Framework will be called:
draft-ietf-mediactrl-sip-control-framework

Editors, in the To: field, make a note of this


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
[e-mail]
https://www1.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl




------------------------------

Message: 19
Date: Thu, 2 Aug 2007 11:53:15 -0400
From: "Haluska, John J" <[e-mail]>
Subject: RE: [MEDIACTRL] MRB - MS Query Interface
To: "Chris Boulton" <[e-mail]>, <[e-mail]>
Message-ID:
        <[e-mail]>
       
Content-Type: text/plain; charset="us-ascii"

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 15375 bytes
Desc: image001.jpg
Url : http://www1.ietf.org/pipermail/mediactrl/attachments/20070802/9643ed72/attachment-0001.jpe

------------------------------

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

End of MEDIACTRL Digest, Vol 8, Issue 2
***************************************

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