Subject: RE: [mediactrl] RE: mixer protocol req. - general protocol comments

From: "Chris Boulton" <[email-masked]>
Date: Wed, 8 Dec 2004 10:27:46 GMT

Some more comments - snipped.

Chris.

General protocol

1. The transport of the protocol should be based on standard protocols (
SIP, H.248)

[timm] although we sometimes consider h.248 as a transport, it clearly
cannot be used simply as a transport because it brings along much
additional functionality. sip is *not* considered a general transport
protocol. tcp, udp, sctp could be considered as transport protocols
and i have sometimes thought that msrp could be a candidate.

RE: The transport here is not a transport protocol but a transport
mechanism for the mixer control protocol.

[Chris Boulton] I think we are all on the same playing field.  The
transport of the mixer protocol will be using a standard protocol BUT
the sessions and it's associated properties could be SIP (as MSRP uses
SIP for sessions control).  I think it is best to leave out examples at
this stage.

I would propose the following:-

The transport of the media mixer protocol should be based on a
standardized protocol mechanism.

3. The protocol should enable many AS to work with the same MS (is this
really needed???)

[timm] we see this out in the world. a large carrier grade MS will
support multiple ASs where a smaller enterprize MS may not. hence,
i think that the capability should be allowed/supported by the
protocol, but not required by an MS.

RE: My question is if there a need to allow many AS to work with one MS
not based on any virtual allocation. This requirement makes it more
complicated for the AS to decide which of the MS he is managing can be
used for a new conference specially if he does not know what is the
resources usage on the MS by the other AS.

[Chris Boulton] It does make it more complicated but I agree that it is
required.  I personally like the idea of decomposing the resource
management into a separate logical entity that can be accessed by an AS
for managing clustered resources.  Any thoughts? OR I am over
complicating?

8. The MS shall be able to tell the AS its functionality (Mixing, IVR,
Announcements)

[timm] agreed that there has to be a capability mechanism somewhere.
i'm not sure it's part of this protocol.

RE: we need to address it if we want AS and MS from different
manufacturers 

[Chris Boulton] Could be part of the resource management idea I
mentioned earlier.

--------------------------
Ubiquity Software does not control or endorse the content, messages or
information found in this mail list and it specifically disclaims any
liability with regard to these communications.
Ubiquity Software reserves the right the restrict access to any
communications in violation of the Terms and Conditions of Use for this
website or as otherwise deemed improper.

This email and any attached files are confidential and copyright protected.  If you are not the addressee, any dissemination, distribution or copying of this communication is strictly prohibited.  Unless otherwise expressly agreed in writing, nothing stated in this communication shall be legally binding.

--------------------------
Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications.
Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper.

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 20 Dec 2004 10:43:37 GMT

I also vote for the latter.  From an AS point of view - we do not need
to know the detail.

Chris.

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: 15 December 2004 19:11
To: Chris Boulton; Tim Melanchuk
Cc: MixerControl
Subject: RE: [mediactrl] RE: mixer protocol req. - general protocol
comments

How about this:

If the protocol assumes virtual media servers, one is hosed if you don't
want to do virtual media servers.

If the protocol does not assume virtual media servers, a virtual media
server is simply an implementation issue and thus totally orthogonal to
the
protocol.

I vote for the latter.

> -----Original Message-----
> From: Chris Boulton [mailto:[email-masked]]
> Sent: Tuesday, December 14, 2004 4:14 AM
> To: Tim Melanchuk; Eric Burger
> Cc: Cullen Jennings; MixerControl
> Subject: RE: [mediactrl] RE: mixer protocol req. - general protocol
> commen ts
> 
> 
> 
> 
> very articulate ;-) and full of assumptions.
> 
> a proper virtualization should make a virtual ms
> look the same as a physical ms to an application.
> such as choice should be up to ms vendors if
> they perceive a marketplace need for such a thing.
> 
> i think our protocol discussions should be more
> focused whether there are any requirements for
> resource/mgt reservation  and if so, how are
> those realized.
> 
> [Chris Boulton] Agreed.
> 
> timm
> 
> 
> 
> Eric Burger wrote:
> > My thoughts on virtual media servers:
> > 
> > barf, barf, barf, barf, barf, barf, barf, barf, barf, barf, barf
> > 
> > [too lazy to do ASCII art of piles of yellow and brown 
> chunky stuff --
> I
> > hope the visual image gets the point across]
> > 
> > Lots of application complexity, lots of application server 
> complexity,
> lots
> > of media server complexity, and at the end of the day, you get less
> > functionality.
> > 
> > Why go there if we don't have to?
> > 
> > 
> > 
> >>-----Original Message-----
> >>From: Cullen Jennings [mailto:[email-masked]]
> >>Sent: Thursday, December 09, 2004 2:21 PM
> >>To: Tim Melanchuk; Eric Burger
> >>Cc: Roni Even; MixerControl
> >>Subject: Re: [mediactrl] RE: mixer protocol req. - general protocol
> >>comments
> >>
> >>
> >>
> >>Can I abstract this away to say that things will generally 
> >>work as: The AS
> >>sends a commend to the MS and says try to make this so. The 
> >>the AS says, yes
> >>I can do that or no, I did not have the 
> >>resources/capabilities to do what
> >>you requested. 
> >>
> >>The questions in my mind is do we have a model where a give 
> bit of DSP
> >>platform was divided into some number of virtual MS and each MS was
> >>configured separately and was controlled by one one AS. Or 
> is the DSP
> >>hardware configured as one MS and many AS can connect to it 
> >>and compete for
> >>the resources on it. I can see eitehr model working.
> >>
> >>I believe we all agree that a single AS can control many MS.
> >>
> >>
> >>
> >>On 12/8/04 5:48 PM, "Tim Melanchuk" <[email-masked]> wrote:
> >>
> >>
> >>>>>not based on any virtual allocation. This requirement 
> >>
> >>makes it more
> >>
> >>>>>complicated for the AS to decide which of the MS he is 
> >>
> >>managing can be
> >>
> >>>>>used for a new conference specially if he does not know 
> >>
> >>what is the
> >>
> >>>>That's H.248-think.  If you use Oracle, do you need to 
> >>
> >>know what resources
> >>
> >>>>the other applications are using?  No.  You ask your 
> >>
> >>query, and either you
> >>
> >>>>get a result or you get told the server is too busy.  Same 
> >>
> >>thing here if
> >>
> >>>>your using a session-level protocol [yes, hidden ding on 
> >>
> >>MGCP-like markups
> >>
> >>>>:-].
> >>>>
> >>>
> >>>afaik, both mgcp and h.248 have response codes indicating 
> the server
> >>>is currently too busy to service a request. so, although i tend to
> >>>agree with the solution, i don't see significant difference here.
> >>>[no hidden dings on any markups ;-) ]
> >>
> This email and any attached files are confidential and 
> copyright protected.  If you are not the addressee, any 
> dissemination, distribution or copying of this communication 
> is strictly prohibited.  Unless otherwise expressly agreed in 
> writing, nothing stated in this communication shall be 
> legally binding.
>