Subject: [XCON] Conference Controllers and Mixers

From: eburger at snowshore.com (Eric Burger)
Date: Thu Jul 17 04:37:28 2003

The problem is, some of the media policy implementation proposals to date (subject to change), effectively dictate a H.248.1 slave relationship between the focus and mixer.  This is because the existing policies pretty much follow H.248.1 semantics.

I would offer that H.248.1 is not the best protocol for an application to interact with a focus (to interact with a mixer).  Here the application is the user agent user interface.

> -----Original Message-----
> From: Even, Roni [mailto:[email-masked]]
> Sent: Thu, July 17, 2003 3:11 AM
> To: 'Bob Hughes'; [email-masked]
> Subject: RE: [XCON] Conference Controllers and Mixers
> 
> 
> Hi,
> I think that I would like to clarify the conferencing 
> architecture. If you
> will look at the sipping conference framework draft that was 
> written by
> Jonathan Rosenberg you will see three different logical entities. The
> conference policy server, the focus and the mixers. You can 
> also look at it
> as an application server that includes the conference policy, 
> a focus which
> does call signaling with EPs or other focus and a mixer that 
> mixes the media
> according to the information from the focus. 
> The XCON is addressing the issue of how an application from a user can
> manipulate the conference policy (including media policy). It is not
> addressing the decomposition of the conference server. For 
> example you can
> say that a conferencing bridge can be one physical unit that 
> includes both
> the focus and the mixer. You can have them in a physical 
> decomposition (BTW
> there is work done by the ITU on H.248.19 which is a package for this
> decomposition). Now in you example the distributed conference 
> can be done
> either by having one focus (or MC (MGC) in Megaco terms) and 
> many mixers (or
> MPs in Megaco terms) in that case it is one conference that 
> has one focus.
> Another way is to have one application server that will  handle many
> conferencing server (MCUs) composed out of focus and mixers, this is a
> cascaded conference. The cascaded solution involves less communication
> between the entities and is more suitable, in my opinion, to 
> geographically
> distributed architecture. It is true that we do not address 
> the issue of the
> communication between the focus and the conference policy server (or
> application server) but rather about how user application can 
> define the
> policy. I assume that this connection can be based on SIP 
> (look at 3GPP AS
> to MRF interface as an example)
> Regards
> 
> Roni Even
> 
> **********************************
> Roni Even
> VP Product Planning
> Polycom Network Systems
> 
> Tel: +972-3-9251200
> Mobile: +972-55-481099
> email: [email-masked]
> *************************************
> 
> -----Original Message-----
> From: Bob Hughes [mailto:[email-masked]]
> Sent: Wednesday, July 16, 2003 6:18 PM
> To: [email-masked]
> Subject: [XCON] Conference Controllers and Mixers
> 
> 
> Steve Fisher wrote the following in a note with a different 
> subject header
> and I wanted to add a couple of comments in favor of moving the
> mixer/controller protocol back in scope.
> 
> Rohan,
> 
> In your response to Eric you state the following goal for xcon:
> 
> "The goal is to allow customers to select a
> conferencing application that can work with many vendor's mixers and
> conference servers."
> 
> I'm puzzled how this goal can be achieved when the protocol 
> between the
> application server and the mixers is explicitly out of scope for xcon?
> According to the charter, the following is out of scope: 
> "Protocol used
> between the conference controller and the mixer(s)."
> 
> Steve
> 
> Please consider:  if conference participants were in 
> different geographies
> (Europe and Aisia, for example) and an enterprise wished to 
> mix in each
> geography to minimize traffic between geos, it is unrealistic 
> to think that
> the mixer in each geography will always be from the same supplier.  It
> seems that a single focus, in this case, is in control of a call with
> multiple mixers (probably from different vendors) and the question of
> protocol becomes pretty important.
> 
> Please consider also:  If the UA has conferencing capability 
> (for, say,
> between 3-6 participants) and the user still accesses the 
> conference server
> (something that certainly happens in real life as not many people can
> handle or be bothered with the key strokes needed to set up 
> conferences on
> a phone), shouldn't the focus have the ability to establish 
> the conference
> on the UA itself (for small conferences and assuming the 
> conference server
> has some awareness of the UA's mixing capability)?  A 
> definition of the
> controller/mixer protocol would be useful here, too.  This is 
> a huge thing
> for the enterprise as many conferences are small and the 
> investment in UAs
> is large.  It seems very desirable if UA based conferencing can be
> accomplished in manner indistinguishable from central mixing 
> from the end
> user's perspective.
> 
> Thanks.
> 
> 
> Program Manager, VoIP and Voice/Data Convergence
> eBusiness On Demand Transformation;  IT Enablement
> 914-514-5016:  TL 725-7242