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

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 8 Aug 2001 11:01:42 -0400

Because I can accomplish everything with one mechanism, properties
of terminations.  I need NO extensions to do this today.  The latter
is very important because while I think providing support for
multimedia bridges is essential to accomplish soon, producing
V2 is not, and I don't want to (and don't have to) confuse the two issues.

It is not true that topology gives me routing; the context does that.
Topology is an imperfect mechanism to control one aspect of a
square matrix mixing bridge.  In an m^2 audio bridge, I want (at least)
a volume control at each cross point.  In an m^2 video bridge,
I want something fairly complex (something on the order of
a clipping rectangle plus a two dimensional transform for the 
crosspoints I think).  For an m^2 text stream bridge, I need something else.

Brian

> -----Original Message-----
> From: Danny Levin [mailto:[email-masked]]
> Sent: Wednesday, August 08, 2001 9:53 AM
> To: 'Rosen, Brian'; 'Christian Groves'; [email-masked]'
> Subject: RE: [Megaco] How to control multimedia conference bridges
> 
> 
> Brian,
> 
> The scope of Topology is to provide a "routing table" for 
> switching and
> mixing.
> The semantics how to mix (put it in 6 windows or scramble the 
> pixels...)
> should be defined in packages.
> 
> Why do you object to add streamID to Topology ? (It just add 
> fine tuning to
> a mechanism that we already have)
> 
> -----Original Message-----
> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Wednesday, August 08, 2001 8:19 AM
> To: 'Christian Groves'; [email-masked]'
> Subject: RE: [Megaco] How to control multimedia conference bridges
> 
> 
> If you use topology to control who hears whom, you need to 
> use topology
> to control my side conversation example.  If you use topology to
> control who hears whom, you use topology to control who sees whom, and
> you get into the issues of video layout.
> If you use properties of terminations to control these things, then
> topology is not very useful.  In my example, the obvious way 
> to control
> the bridge is to allow each listener to have a volume control 
> per talker.
> Easy to do with a package.  It IS possible to add this to 
> topology, but
> as I said, what do you do for the next feature?
> 
> Adding context parameters has some charm, some problems, but the only
> thing it does is give you some cosmetic advantage, where you can set
> a parameter on a context instead of on one or more of the 
> terminations.
> I'm having a little problem coming up with good examples, primarily
> because every time I think I have one, I then think of a variant that
> has a per-termination aspect.  Perhaps you can cite an example.
> 
> BTW, rather than actually add context parameters, I'd rather add a 
> characteristic to a property which was "Context-Global".  This is
> would be a much simpler update.
> 
> Brian
> 
> 
> 
> > -----Original Message-----
> > From: Christian Groves [mailto:[email-masked]]
> > Sent: Wednesday, August 08, 2001 5:42 AM
> > To: [email-masked]'
> > Subject: Re: [Megaco] How to control multimedia conference bridges
> > 
> > 
> > You seem to have missed the point. The topology descriptor won't be
> > extended to include "all types of things". The only thing 
> > that has been
> > proposed on this list is to add a stream ID. I believe 
> Danny proved a
> > case where it was needed.
> > 
> > Yes I agree with your extensibility statement that's why in 
> v2 you can
> > extend the context attributes through the use of packages 
> the same way
> > you do terminations. We've already done this and as you say the next
> > idea is only a package away.
> > 
> > Christian
> > 
> > "Rosen, Brian" wrote:
> > > 
> > > I do not agree that it is appropriate to continuously 
> > enhance topology
> > > to handle all the interesting things people might want to do.
> > > 
> > > Here is one example
> > > 
> > > Suppose I had an audio bridge that would allow side conversations
> > > while monitoring the main conference.  The output to each listener
> > > is (potentially) custom, and consists of a mix of the main 
> > conference
> > > less all side conversation talkers at a lower volume, 
> plus its side
> > > conversation.
> > > 
> > > What changes to topology might be required to describe such 
> > a bridge?
> > > More importantly, will we have to make more changes when the next
> > > interesting idea comes along?  Are we going to allow packages to
> > > extend topology?
> > > 
> > > Take video.  What is the topology descriptor that 
> describes 6 small
> > > windows on the left and bottom of a large window?
> > > 
> > > I say, NO, don't go there.  It is quite simple to do this all with
> > > properties of terminations, and the next great idea is 
> just another
> > > package away.
> > > 
> > > Note I do think a context containing the terminations of the
> > > members of the conference is fine; I just think using topology
> > > and context parameters to control the bridge is not appropriate
> > > because the range of possibilities demands extensibility.
> > > 
> > > Brian
> > > 
> > > > -----Original Message-----
> > > > From: Christian Groves [mailto:[email-masked]]
> > > > Sent: Wednesday, August 08, 2001 1:21 AM
> > > > To: [email-masked]'
> > > > Subject: Re: [Megaco] How to control multimedia 
> conference bridges
> > > >
> > > >
> > > > 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
> > > >
> > > > "Rosen, Brian" wrote:
> > > > >
> > > > > 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
> > > >
> > > > _______________________________________________
> > > > 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: Thu, 09 Aug 2001 15:46:58 +1000

G'Day Brian, all,

I that we're not digressing about 20 months into arguments about
topology. I hope we don't have to go back there, to the 100+ emails on
the thread, that's why I kept out of the SIP compression arguments, it
gets too tiring. It seems not everyone is comfortable with topology  - 
no surprise that every MSF profile written says that topology isn't to 
be supported. I wonder who input on that ;)? 

Topology gives you control over exactly what switching you have in a
context. Rather than having purely mixing/conferencing it enables you
describe the internal connections of the context. You cannot do this
using a TID, Context and streammode alone.

Topology has never reported to be a mechanism to describe the algorithms
on mixing data ie. transforming video, and I haven't heard anyone apart
from yourself saying that topology is extended to do this. I agree with
you that packages are needed for terminations to describe the lay out
etc. Effectively its the same as putting a codec on an audio stream. 

Adding a streamID I still believe is a useful enhancement of topology as
you may want to have a seperate switching treatment for audio and video.

For those wanting to forward the work on conferencing bridges and MCUs
why not produce a list of functions that need to be supported. ie. What
type of mixing? Floor control? Gain Control? Auditing number of devices?

Once identified, when can then tick each item off to see where it
belongs ie. termination, context, stream and then write an appropriate
package. I don't think a phone conference is worthwhile unless we have
an input document on functionality to discuss.

I think adding enhancements H.248v2 to allow for additions to the
protocol without having to open up the core document in future is a good
thing. Context Attributes are one such area.

Regards, Christian