Subject: RE: [Megaco] How to control multimedia conference bridges

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 7 Aug 2001 10:01:06 -0400

We must be misunderstanding each other.

I was imagining that for every "port" on the bridge, you created an 
ephemeral that implemented RTP/ATM.... and the packages that were 
(to be) defined for managing the bridge.  By manipulating the 
properties of the termination, you controlled the operation
of the bridge.  All the parties in a conference would be in 
a context.

If you had a physical port on the bridge, you could represent it as 
a physical termination.  You could include this termination in the 
context for the conference, implementing the bridge control package(s) 
on these terminations (my choice), or you could create a PAIR of ephemerals 
with an implied (RTP) connections between the pair, putting one in a two
terminal context and the other in the bridge context (hairpin).  
In the latter, you essentially duplicate a remote MG with a 
physical/ephemeral pair.  The hairpin could eliminate the packet flow 
and/or RTP encapsulation between the ephemerals. 

Does that better explain how I see it working?

BTW, a while ago, I offered another model, where each port of the 
bridge was an ephemeral termination, and it was connected to either 
a physical termination or an RTP/ATM... ephemeral in a series of
two termination contexts.  In this model, a parameter of the
bridge port was a "conferenceID", and every termination with
the same conferenceID was mixed.  While this is actually a more
flexible model, it just looks weird - not using the context to
define the parties in the conference, so I no longer talk about it.
It has the obvious advantage in the example you cite.  

Brian

> -----Original Message-----
> From: Danny Levin [mailto:[email-masked]]
> Sent: Tuesday, August 07, 2001 9:44 AM
> To: 'Rosen, Brian'; Danny Levin; 'Flemming Andreasen'
> Cc: [email-masked]'
> Subject: RE: [Megaco] How to control multimedia conference bridges
> 
> 
> Brian,
> 
> MGCP is not the scope of this discussion although I don't 
> think that hairpin
> solves the problem because it is limited to only 2 endpoints 
> (as far as I
> know it was not designed for this purpose).
> 
> Why can't we improve the "routing" mechanism to enable 
> control in the level
> of streams for any type of application.
> It does not prevent us to define packages for video conferencing.
> 
> 
> 
> -----Original Message-----
> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Tuesday, August 07, 2001 5:48 AM
> To: 'Danny Levin'; 'Flemming Andreasen'
> Cc: [email-masked]'
> Subject: RE: [Megaco] How to control multimedia conference bridges
> 
> 
> Either you allow the bridge to have physical terminations or 
> you hairpin.
> 
> Brian 
> 
> > -----Original Message-----
> > From: Danny Levin [mailto:[email-masked]]
> > Sent: Monday, August 06, 2001 8:28 PM
> > To: 'Flemming Andreasen'; Danny Levin
> > Cc: 'Rosen, Brian'; [email-masked]'
> > Subject: RE: [Megaco] How to control multimedia conference bridges
> > 
> > 
> > Flemming,
> > 
> > You can add to a virtual endpoint only connections and not 
> > other endpoints.
> > What do you do if you need to add another physical endpoint to the
> > conference ?
> > 
> > (you always can work around but it is not a straight 
> forward solution)
> > 
> > BTW we are trying to solve a problem in MEGACO.  I have 
> > nothing against
> > MGCP.... 
> > 
> > Danny.
> > 
> > 
> > 
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:[email-masked]]
> > Sent: Monday, August 06, 2001 7:13 PM
> > To: Danny Levin
> > Cc: 'Rosen, Brian'; [email-masked]'
> > Subject: Re: [Megaco] How to control multimedia conference bridges
> > 
> > 
> > 
> > 
> > Danny Levin wrote:
> > 
> > > Brian,
> > >
> > > A Conference is a private case of communication. Therefore 
> > the generic
> > > mechanism should support it.
> > > (One of the advantages of MEGACO (versus MGCP) is a more 
> > generic abstract
> > > model...).
> > 
> > > Context and topology should enable more flexibility not 
> > necessarily just
> > for
> > > conferences.
> > >
> > 
> > Non-sense. Use a virtual endpoint and define a conference 
> > control package if
> > you
> > need something more sophisticated than the "conference" 
> > connection mode
> > defined
> > in the base protocol.
> > 
> > -- Flemming
> > 
> > 
> > 
> > >
> > > However I do agree that there is a space for packages for specific
> > behaviors
> > > (such as voice activation for video conferencing).
> > >
> > > Danny.
> > >
> > > -----Original Message-----
> > > From: Rosen, Brian [mailto:[email-masked]]
> > > Sent: Monday, August 06, 2001 11:49 AM
> > > To: [email-masked]'
> > > Subject: [Megaco] How to control multimedia conference bridges
> > >
> > > A continuing issue in Megaco is how to control a 
> conference bridge.
> > > The basic issue we have not resolved is the basic 
> mechanism - should
> > > the control be via context and topology controls, or should it be
> > > via packages (i.e. properties/events/signals on terminations).
> > >
> > > I believe that there are a great many variables, and lots 
> of models
> > > of conference bridges and their resulting control needs.  
> No amount
> > > of messing around with context and topology will suffice. 
>  However,
> > > we can straightforwardly create packages for the terminations,
> > > and thus reasonably deal with any future requirements with
> > > the package mechanism.  I would like to see conference 
> > mechanisms prior
> > > to V2, thus I don't want to see conference support tied to V2.
> > >
> > > I would therefore propose that we undertake to define a 
> package for
> > > the more common conference bridge functions in the Megaco WG.
> > >
> > > I would further propose that we start with a discussion of 
> > requirements.
> > >
> > > I know that there are folks who strongly feel that topology and
> > > context parameters are the way to do conference control, so 
> > I would like
> > > to see if we can come to consensus on that issue first.  
> > Requirements
> > > should be common, so we can work on them as we discuss the basic
> > > mechanism.
> > >
> > > Brian
> > >
> > > _______________________________________________
> > > Megaco mailing list
> > > [email-masked]
> > > http://www.ietf.org/mailman/listinfo/megaco
> > >
> > > _______________________________________________
> > > Megaco mailing list
> > > [email-masked]
> > > http://www1.ietf.org/mailman/listinfo/megaco
> > 
> > --
> > Flemming Andreasen
> > Cisco Systems
> > 
> > 
> > 
> > _______________________________________________
> > Megaco mailing list
> > [email-masked]
> > http://www1.ietf.org/mailman/listinfo/megaco
> > 
> > _______________________________________________
> > Megaco mailing list
> > [email-masked]
> > http://www1.ietf.org/mailman/listinfo/megaco
> > 
> 
> _______________________________________________
> Megaco mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/megaco
> 

_______________________________________________
Megaco mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/megaco

---

From: Christian Groves <[email-masked]>
Date: Wed, 08 Aug 2001 15:20:41 +1000

I think the solution for a conference bridge is somewhat of a hybrid
solution. Sure you can describe alot of things on the termination level.
ie. floor control. Someother things such as topology, mixing algorithms
etc however relate to the context. Thus we need additional context
properties. In the development of H248v1 it was always said further work
was needed on this scenario and in fact the current definition of
context states: "The Context describes the topology (who hears/sees
whom) and the media mixing and/or switching parameters if more than two
Terminations are involved in the association."

I don't see why the H.248 model for 3 terminations in a context implies
a conference call but now it is proposed that a "special conference"
package is needed to indicate a conference. 

So far on the list I've seen a need for:
o identification of a conference > we can do this with having multiple
terminations in a context as we do today, nothing else is needed.
o a package for floor control 
o stream identification in the topology descriptor for stream routing
for different media.

What other requirements for functionality are there (I'm sure there's
more)?

Christian