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

From: Eric Burger <[email-masked]>
Date: Wed, 8 Dec 2004 11:17:09 GMT

My comments in-line.

> -----Original Message-----
> From: Even, Roni [mailto:[email-masked]]
> 
> Tim,
> I was going through the comments. inline
> 
> -----Original Message-----
> From: Tim Melanchuk [mailto:[email-masked]] 
[snip]
> 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
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
:-].

> 4. The AS should be able to find the MS and connect to it.
> 
> [timm] what protocol mechanisms do you think are required 
> here? i would
> hope that we could utilize existing dns or ther mechanisms without
> requiring this protocol to define discovery mechanims. also, should
> control
> connections always be initiated from the AS to the MS, should 
> it be the
> other direction, or should either be allowed/supported? for example
> mgcp and h.248 are initiated from the gateway.
> 
> RE: I am still on the requirement phase.

SIP Proxies solved this years ago, but I get ahead of the requirements.

> 7. The MS shall be able to tell the AS its capacities.
> 
> [timm] this gets into the resource management area, which i think is
> important but also potentially complex. how are capacities defined
> and what gets reserved. i think something simple is possible, but
> it can be difficult to define standard definitions here.
> 
> RE: see my response to multiple AS with one MS. It is also 
> for enabling
> the MS to inform the AS about malfunction.

I see this as what we in America call "Motherhood and Apple Pie."  That is,
you cannot be against such a requirement as the use cases are so varied it
isn't worth enumerating them all.

> 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 

Actually, the MS needs to tell its proxy its functionality.  If it sounds
like there is still life in the MRF-C, there is.  However, since to the MS
there is no difference between a Proxy and an AS (isn't this the POINT of
SIP?), I can live with the current wording.

> 9. The AS shall be able to create and delete sessions on the MS.
> 
> [timm] i think that session establishment should be 
> *explicitly* out of
> scope for this protocol. sip is an example of a session establishemnt
> protocol that works well in the context of application and media
> servers.
> the protocol should be focused on conference application 
> functionality,
> and not duplicate things found in other protocols.
> 
> RE: your comment is a solution. The requirement is for the AS 
> to be able
> to start a mixing session on the MS

Then say it that way: The AS shall be able to request the MS to create,
delete, and manipulate a mixing session.

> 10. The MS shall supply the media addresses (RTP transport address) to
> be
> used to the AS.
> 
> [timm] see above. i would make the assumption that the AS learns
> this using the session establishemnt protocol. if for some reason
> the AS is *not* on the session establishment signalling path, then
> an extension could be developed to allow the AS learn about
> all of the media parameters for a session.
> 
> RE: you are assuming a specific transport.

This is only a requirement if you use a brain-dead protocol like H.248,
MGCP, or MGCP in XML.

[snip]

> 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?
--------------------------
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: Tim Melanchuk <[email-masked]>
Date: Thu, 9 Dec 2004 01:19:53 GMT

at the end below...
Eric Burger wrote:
-----Original Message-----

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 ;-) ]
--------------------------
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: Cullen Jennings <[email-masked]>
Date: Thu, 9 Dec 2004 18:52:05 GMT

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.