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

From: Eric Burger <[email-masked]>
Date: Wed, 8 Dec 2004 12:36:59 GMT

I would vote for IP only.  SIP vs. H.323 is purely an XCON issue.

> -----Original Message-----
> From: Even, Roni [mailto:[email-masked]]
> Sent: Wednesday, December 08, 2004 7:12 AM
> To: Eric Burger
> Cc: [email-masked]
> Subject: RE: [mediactrl] RE: mixer protocol req. - general protocol
> comments
> 
> 
> Eric,
> 
> I think that we need to decide on the scope of the work. Are we
> addressing only IP (RTP?) media sessions or do we support also circuit
> switch. For IP do we support only SIP UAs or also H.323 (this is not
> relevant to the media server but to the application server and its
> decisions)
> 
> 
> > 19. The AS shall be able to tell the MS which codecs to use on 
> > incoming and out going streams
> > 
> > [timm] as above, i think this is part of session 
> establishment and out
> 
> > of scope for the protocol. service providers that use sip 
> can use the 
> > session policy mechanisms currently being developed to define the 
> > media policy in their networks.
> > 
> > RE: The session policy is between the user/administrator 
> and the AS. 
> > Now the AS needs to be able to force this policy on the 
> media server. 
> > This is the part we are trying to address here.
> 
> Well, we do this in the real-world.  However, it is entirely 
> orthogonal
> to the control protocol.  Either a service provider does not care, or
> they care about all calls being compressed.  We haven't ever seen a
> per-session need for this.  Have you?
> 
> RE: The requirement will always be met if we select a 
> solution where the
> AS is in the signaling path and may change the codecs offered 
> to the MS.
> 
> The comments from you or Tim assume UA that talk SIP and that SIP is
> used between the AS and MS. 
> 
> Roni
> 
> 
> 
--------------------------
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: Eric Burger <[email-masked]>
Date: Wed, 8 Dec 2004 15:37:12 GMT

Exactly as you propose: Conference events is purely an AS thing.
Requirement is for MS to give AS information sufficient to populate event
package.

> Sent: Wednesday, December 08, 2004 10:36 AM
> To: Eric Burger
> No problem agreed.
> The next question is where do we have the conference event package, is
> it on the AS or the MS. My assumption is that it is on the 
> AS. This will
> require the MS to report the SSRC or stream identifiers to the AS.
> Roni
> 
> From: Eric Burger [mailto:[email-masked]] 
> Sent: Wednesday, December 08, 2004 2:58 PM
> To: Even, Roni

---

From: Eric Burger <[email-masked]>
Date: Thu, 9 Dec 2004 14:57:30 GMT

> From: Tim Melanchuk [mailto:[email-masked]]
> 
> at the end below...
> 
> Eric Burger wrote:
> 
[snip]
> > 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 ;-) ]

The issue is that with H.248 or MGCP, the ASSUMPTION is the "controller"
(a.k.a. MGC) knows the precise resource utilization of the MS, because there
can be one and only one controller per [virtual] MS.

The assumption with client/server protocols is the server manages its own
resources.  Hence the distinction.

Yet another reason why the requirement for multiple AS using resources on a
single MS automatically rejects H.248 or MGCP.  QED
--------------------------
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: Tue, 14 Dec 2004 08:51:11 GMT

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?
> 
> 
> 
>>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:
>>
>>
>>>>>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.
>>>>
>>>>
>>>>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
>>
> 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.
--------------------------
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.

---

From: Eric Burger <[email-masked]>
Date: Wed, 15 Dec 2004 18:47:31 GMT

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.

> From: Chris Boulton [mailto:[email-masked]]
> Sent: Tuesday, December 14, 2004 4:14 AM
> Cc: Cullen Jennings; MixerControl
> commen ts
> 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.
>