Subject: [Megaco] How to control multimedia conference bridges

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 6 Aug 2001 11:49:14 -0400

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

---

From: Vladimir Brauner <[email-masked]>
Date: Tue, 7 Aug 2001 01:14:47 +0200

Brian,

As far as for one set of our needs which was to setup a prepaid conferencing
app w IVR, we had no problem using the Topology mecanism, exactly as it is
specified. We feel this mecanism is very consistent with Megaco Call Model
and actually does the job, especially as signals can be applied to each
termination without disrupting the mixing matrix. We also use Topology for
call hold, agent monitoring, recording, etc. and it proves to be quite ok
for many situations.

Some new context props may nevertheless make implementations simpler and
more efficient, but we feel this existing mecanism is a very good starting
point.
Is there any already existing list of cases which may appear not feasible
with it ?

Vlad

-----Message d'origine-----
De : Rosen, Brian [mailto:[email-masked]]
Envoyé : lundi 6 août 2001 17:49
À : [email-masked]'
Objet : [Megaco] How to control multimedia conference bridges

Brian

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

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 7 Aug 2001 05:47:45 -0400

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
> >
> --
> Flemming Andreasen
> Cisco Systems

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 7 Aug 2001 05:40:52 -0400

I suppose it's all in your definition, but let's take the case of a video
bridge.  Most video bridges have a variety of output formats that have to do
with the relative sizes and placements of the source windows in the output
stream.  The context mechanism, as defined, is a mixing bridge.  What is
a mixing bridge for video?  I can use topology to control a simple audio
bridge, but, as currently defined, I can't use it for a video bridge.

We have two choices - we can enhance the context and topology models to
cover our current understanding of video bridge capabilities, but I suspect
that we can't really anticipate all the possible warping of context/topology
to cover every case, and then we bring in things like T.120, and it gets
even more complicated.

On the other hand, implementing all the controls required as properties of
the terminations is straightforward.

Brian

> Sent: Monday, August 06, 2001 5:22 PM
> To: 'Rosen, Brian'; [email-masked]'
> A Conference is a private case of communication. Therefore the generic
> necessarily just for
> However I do agree that there is a space for packages for 
> specific behaviors

---

From: Danny Levin <[email-masked]>
Date: Tue, 7 Aug 2001 08:44:10 -0500

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

Brian

---

From: "Even ,Roni" <[email-masked]>
Date: Tue, 7 Aug 2001 21:01:07 +0200

Vlad,
I guess it is an audio conferencing bridge. We are trying to support
multimedia, including video were mixing is not simple. There can be
different layouts that can be made and different participants in each window
in the layout. 
Roni Even

-----Original Message-----
From: Vladimir Brauner [mailto:[email-masked]]
Sent: Tuesday, August 07, 2001 1:15 AM
To: [email-masked]'
Subject: RE: [Megaco] How to control multimedia conference bridges

Brian,

Vlad

-----Message d'origine-----
De : Rosen, Brian [mailto:[email-masked]]
Envoyé : lundi 6 août 2001 17:49
À : [email-masked]'
Objet : [Megaco] How to control multimedia conference bridges

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 8 Aug 2001 08:18:47 -0400

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

> From: Christian Groves [mailto:[email-masked]]
> Sent: Wednesday, August 08, 2001 5:42 AM
> To: [email-masked]'
> 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
> > 
> > > From: Christian Groves [mailto:[email-masked]]
> > > Sent: Wednesday, August 08, 2001 1:21 AM
> > > To: [email-masked]'
> > > 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
> > > >
> > > > > Sent: Tuesday, August 07, 2001 9:44 AM
> > > > > To: 'Rosen, Brian'; Danny Levin; 'Flemming Andreasen'
> > > > > Cc: [email-masked]'
> > > > > > > context parameters are the way to do conference 
> control, so
> > > > > > I would like

---

From: Danny Levin <[email-masked]>
Date: Wed, 8 Aug 2001 08:53:20 -0500

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

Brian

---

From: "Even ,Roni" <[email-masked]>
Date: Wed, 8 Aug 2001 20:25:13 +0200

Hi, 
I am resending the text since it was not on the list due to the size of the
attachment.
I submitted a contribution to the last ITU SG16 Q3 meeting that describe a
model for MCU decomposition that included a video mixer and audio mixer
terminations that can be part of the context and that will have new packages
for conferencing. There was an objection to use a mixer termination and the
request was to use the V2 features. In order to develop a conferencing
package we must agree on the architecture. I started to prepare a new
contribution based on V2 feature for the ITU SG16 September meeting. I think
that we need to agree on an architecture. I prefer the architecture
described in my previous contribution for the reasons you mentioned but I
have no major objection to use the V2 feature as long as they will be
approved by Feb 2002. The relevant features include context parameters and
adding stream-ID to topology which will also be contributed to the ITU
meeting. The contribution will be available by Tom Taylor on the ftp site.

I think that I will have the two architecture options but I would like to
have some consensus on which way to go and if H.248 V2 will be at the
proposed date.

Regards
Roni Even

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Wednesday, August 08, 2001 5:02 PM
To: 'Danny Levin'; 'Christian Groves'; [email-masked]'
Subject: RE: [Megaco] How to control multimedia conference bridges

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

> Sent: Wednesday, August 08, 2001 9:53 AM
> To: 'Rosen, Brian'; 'Christian Groves'; [email-masked]'
> > > > > > > > I believe that there are a great many 
> variables, and lots
> > > > > > of models
> > > > > > > > of messing around with context and topology 
> will suffice.
> > > > > >  However,
> > > > > > > > I would further propose that we start with a 
> discussion of
> > > > > > > requirements.
> > > > > > > >

---

From: Danny Levin <[email-masked]>
Date: Wed, 8 Aug 2001 13:10:48 -0500

what about a conference call in order to get a consensus before ITU-T
meetings.
Please let me know if you are interested and what date/time is best for you.

Danny.

-----Original Message-----
From: Even ,Roni [mailto:[email-masked]]
Sent: Wednesday, August 08, 2001 2:25 PM
To: 'Rosen, Brian'; 'Danny Levin'; 'Christian Groves'; [email-masked]'
Subject: RE: [Megaco] How to control multimedia conference bridges

Hi, 

Regards
Roni Even

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Wednesday, August 08, 2001 5:02 PM
To: 'Danny Levin'; 'Christian Groves'; [email-masked]'
Subject: RE: [Megaco] How to control multimedia conference bridges

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 8 Aug 2001 14:55:37 -0400

I'm willing.  I'm pretty tied up this week, pretty available next week, with
the possible exception of Wednesday.

Brian

> Sent: Wednesday, August 08, 2001 2:11 PM
> To: 'Even ,Roni'; 'Rosen, Brian'; Danny Levin; 'Christian Groves';
> [email-masked]'
> > > > > > > solves the problem because it is limited to only 
> 2 endpoints
> > > > > > > (as far as I
> > > > > > > Either you allow the bridge to have physical 
> terminations or
> > > > > > > you hairpin.
> > > > > > >
> > > > > > > Brian
> > > > > > >
> > > > > > > > > of conference bridges and their resulting 
> control needs.
> > > > > > > No amount
> > > > > > > > > I would therefore propose that we undertake 
> to define a
> > > > > > > package for
> > > > > > > > > to see if we can come to consensus on that 
> issue first.
> > > > > > > > Requirements

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 9 Aug 2001 08:26:48 -0400

Just to be clear, I'm not advocating deprecating topology.  I'm not
thrilled about adding something to it, but I'm willing to support
the addition of streamId.

What I am adamant about is requiring support of topology in order 
to support any manner of conference bridge MG I can think of - that is, 
I want to be ABLE to have an MGC control an MG that implements bridge 
functions without requiring either end implement topology.  
If both ends support topology, and wants to use it to accomplish 
some task, fine.  Support of topology is optional, and I want to
keep it that way.

I'm pretty sure that this is less controversial that it may appear,
given what Christian says.  If, for example, we have a volume
control per talker as properties of the listener termination,
and a single volume control per talker in the talker termination,
then I can control a simple mixer bridge, and I can support
my more complex examples (side conversations).  

I also support requirements gathering prior to design of packages.

Brian

> Sent: Thursday, August 09, 2001 1:47 AM
> To: [email-masked]'
> 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
> 
> 
> 
> 
> "Rosen, Brian" wrote:
> > 
> > > > > > > > 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
> > > > > > > > > > However I do agree that there is a space 
> for packages
> > > > > > for specific
> > > > > > > > > behaviors
> > > > > > > > > > the package mechanism.  I would like to see 
> conference
> > > > > > > > > mechanisms prior

---

From: "Even ,Roni" <[email-masked]>
Date: Thu, 9 Aug 2001 22:12:54 +0200

Brian,
I agree with your statement about being able to control from the termination
the mixing the way by muting the termination and controlling the audio and
video "volume" in the termination. This may help us with getting over the
problem since it will not nee to define a mixer termination. The MP will
have to understand the mixing from the parameters of all the termination in
the context but this will work. I agree that it will be better to define
requirements before packages and that is the purpose of finishing the
architecture before going to packages. I will try to have as part of the
work a list of feature that are needed to be managed for conference bridges.

Roni Even

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Thursday, August 09, 2001 2:27 PM
To: 'Christian Groves'; [email-masked]'
Subject: RE: [Megaco] How to control multimedia conference bridges

Brian

---

From: "Even ,Roni" <[email-masked]>
Date: Fri, 10 Aug 2001 14:08:33 +0200

Hi,
Brian suggestion will help with having another method to control the mixing
without the topology and to me it looks simpler. There are some other issues
I want to raise that have to do with the context level parameters and I will
be happy to get opinion how to solve them without having context level
package (another V2 feature)

1. The MP have to tell the MC its capacity when it starts and to send
updates on current capacities. parameters like mixing option (video mix -
how many , which layouts, audio mix - how many can be mixed) or codecs
supported. I think this can be done by defining packages and having them on
the root termination.

2. For creating conferences to allocate the resources (reserved conferences)
- this can be done by adding all the required termination to the context in
one transaction. - the MP must be able to pre allocate so that if he does
not have enough resources it will be known when the MC tries to create the
conference.

3. Define the initial layout for video - It is not enough to have N
termination which are silent according to Brian proposal or to use the
stream ID. there can be different layout with the same number of
participants and there is also a need to specify which stream is in which
window.

4. For audio to define the mix level - this can be done by having the number
of streams to mix not silent in the termination but then how do you tell the
MP that from the 10 participants you mix the 3 loudest out of the sub group
of 5 while the rest are listeners. I think that can be done by having a
listener and talker terminations and in the example there will be 5
listeners 5 talkers and from the 5 talkers there will be 3 with the volume
control open.

5. The talker terminations need to be able to signal the audio level even if
not in the mixed stream to enable the MC to control the audio mix or voice
activated video switching if he does not want the MP to do it himself. The
MC must be able to define to the context if it will make its own decision or
if it let the MC do it. 

These are some of the issues I had when I thought about the architecture. I
need help for point 3 and 5 if you have any idea how to do it without having
context level parameters.

thanks
Roni Even

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Thursday, August 09, 2001 2:27 PM
To: 'Christian Groves'; [email-masked]'
Subject: RE: [Megaco] How to control multimedia conference bridges

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 13 Aug 2001 14:14:19 -0400

> supported. I think this can be done by defining packages and 
Agree.  We need properties that define limits, like the
how-many-terminations
-per-context property

> not have enough resources it will be known when the MC tries 
Seems to me if you solve #1 above, then you should not have much
trouble with this one - the MGC keeps track of how much resource
it has allocated and never asks the MG to overallocate.  I do think
this can get problematic, but if you do the setup "up front", you
will get an error if any part didn't work.  

> participants and there is also a need to specify which stream 
In my proposal, if you thought through the "views" idea, I think it does
what you want.  In the simple case, there is one view, seen by all
viewers.  Since it's all done with properties, StreamId is specifiable.
What you can't (ever) do is mix streams.  I don't see where that is
an issue.  Do you have any use case in mind where there is more than
one video streamId?

> listeners 5 talkers and from the 5 talkers there will be 3 
Maybe I don't understand the problem, because it seems simple to me;
if you have 3 loudest of 5, the only control is "which 5".  That could
be a property for each termination that specifies if it's in the talker
group or not.  You can also make the termination recieve-only if it's not
in the talker group.

> MC must be able to define to the context if it will make its 
Again, seems simple to me to have a control that enables selection of
talkers from loudest set of designated talkers.  That could be independent
of level for each talker, although a level of zero is another good
indication of "not a talker", isn't it?

Brian

---

From: "Even ,Roni" <[email-masked]>
Date: Tue, 14 Aug 2001 10:16:31 +0200

Brian thanks,
I think that by using packages at the termination levels and have a capacity
and limits package that will be in the root termination we can have a
workable solution without needing version 2.
Roni Even

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Monday, August 13, 2001 8:14 PM
To: 'Even ,Roni'; 'Christian Groves'; [email-masked]'
Subject: RE: [Megaco] How to control multimedia conference bridges

Brian

---

From: Danny Levin <[email-masked]>
Date: Tue, 14 Aug 2001 09:36:02 -0500

Roni,

It seems to me , based on the requirements that you put, that the package
will include many features.
I am not sure that every MG vendor will support all these features .
Since there is no way for the MG to tell the MGC that it supports only a
subset, I suggest that you will define layers of packages. (the basic one
should be simple).

BTW for very complex scenarios I would consider scripts...

Danny.

-----Original Message-----
From: Even ,Roni [mailto:[email-masked]]
Sent: Tuesday, August 14, 2001 4:17 AM
To: 'Rosen, Brian'; Even ,Roni; 'Christian Groves'; [email-masked]'
Subject: RE: [Megaco] How to control multimedia conference bridges

Brian thanks,

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Monday, August 13, 2001 8:14 PM
To: 'Even ,Roni'; 'Christian Groves'; [email-masked]'
Subject: RE: [Megaco] How to control multimedia conference bridges

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 14 Aug 2001 10:55:42 -0400

I think layers of packages is a pretty good idea, although some of the
mechanisms I am thinking about are pretty straightforward to implement
with minimal layering.  For example, the views idea works well with
one view per conference or one view per participant.  You could
consider a simpler mechanism with an enumerated type of fixed
format display.  I'd actually argue against that -- I'd rather have
the view, and constrain the values of the windows to fit into the
fixed values.  I'll have to think about how you would audit to find
out such values - it may just work to auditcapabilities the view
parameters - if they were really fixed, you would get an output
descriptor (with simple values) per possible view.

Audio could use a layer where the base layer has a simple
level per listener, and then add a layer that got you level per
talker on each listener (with the level-per-listener the "master"
level control).  If you needed to have the "designated talker"
function you could either make that a layer, or just have the
value forced on for simple bridges.

I'd like to finish the requirements document first.....

Brian

> Sent: Tuesday, August 14, 2001 10:36 AM
> To: 'Even ,Roni'; 'Rosen, Brian'; 'Christian Groves'; 
> [email-masked]'

---

From: "Even ,Roni" <[email-masked]>
Date: Wed, 15 Aug 2001 13:22:33 +0200

Hi,
I agree that there is a problem with defining what is the base set and what
is optional. Even for a base set we can argue and then for the layered
packages. We will need an option to have as part of the root termination
parameters that specify the limits of the MG. Maybe it can serve for
defining some basic modes supported. I think that the problem is with
defining the video caps. Maybe the model should be to have three base modes
which are video switch, video mix with no transcoding and video mix with
transcoding can be defined and as for video layout I do not want to limit
the model (e.g. no overlays) so we need a model that is extensible. 
Roni Even

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Tuesday, August 14, 2001 4:56 PM
To: 'Danny Levin'; 'Even ,Roni'; 'Christian Groves'; [email-masked]'
Subject: RE: [Megaco] How to control multimedia conference bridges

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 17 Aug 2001 14:19:13 -0400

I think once we agree on requirements, we can see how complex
the layering has to be.  I'm ever optimistic we can make it
reasonably simple.

One thing you do get with layers is easy audit; you do
an audit of packages and you can see what layers are
implemented.  See the thread(s) on auditing of
non-existent ephemerals for some issues.

One non-problem is transcoding.  That is all in the SDP.
If the device can transcode, it will accept SDP that allows
different ports to have different codecs.  If it can't,
it won't.  Nothing else is needed, I think.

Brian

> Sent: Wednesday, August 15, 2001 7:23 AM
> To: 'Rosen, Brian'; 'Danny Levin'; Even ,Roni; 'Christian Groves';
> [email-masked]'

---

From: "Even ,Roni" <[email-masked]>
Date: Sun, 19 Aug 2001 08:52:14 +0200

Brian,
I would like to be would like to be able to find the capabilities of the
conferencing bridge like being able to transcode and what codecs and how
many during bridge start up. this maybe required for reserving conferences
by the MGC which knows the resources it can use on all MGs that are
controlled by it. This information is needed before the actual creation of
the context when the conference need to be schedules. Otherwise, in order to
guarantee the reservation the MG must handle the reservations.
Roni Even

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Friday, August 17, 2001 8:19 PM
To: Even ,Roni; 'Danny Levin'; 'Christian Groves'; [email-masked]'
Subject: RE: [Megaco] How to control multimedia conference bridges

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Sun, 19 Aug 2001 11:53:04 -0400

Auditing Media would provide you the information you are looking
for, although I'm not sure we really figured out how you express
quantity if you AuditCapabilities of Media.

Brian

-----Original Message-----
From: Even ,Roni
To: 'Rosen, Brian'; Even ,Roni; 'Danny Levin'; 'Christian Groves';
[email-masked]'
Sent: 8/19/01 2:52 AM
Subject: RE: [Megaco] How to control multimedia conference bridges

Brian,
I would like to be would like to be able to find the capabilities of the
conferencing bridge like being able to transcode and what codecs and how
many during bridge start up. this maybe required for reserving
conferences
by the MGC which knows the resources it can use on all MGs that are
controlled by it. This information is needed before the actual creation
of
the context when the conference need to be schedules. Otherwise, in
order to
guarantee the reservation the MG must handle the reservations.
Roni Even

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Friday, August 17, 2001 8:19 PM
To: Even ,Roni; 'Danny Levin'; 'Christian Groves'; [email-masked]'
Subject: RE: [Megaco] How to control multimedia conference bridges

Brian

---

From: "David Cromwell" <[email-masked]>
Date: Mon, 20 Aug 2001 11:24:30 -0400

Agreed. Handling resource reservation on the MG is not appropriate.  The MGC
should discover the resources available on the MG via an audit at MG
startup.   The MGC would then keep track of the available resources as calls
come and go.  There is additional complexity if the resources available on
the MG are not ubiquitous, i.e. if a conference is limited to a subset of
the resources available on the MG, for example a particular dsp or group of
dsp's or a particular card or card set.  There also may be partitioning of
resources by functional type, e.g. audio, video, etc.  In both cases the MGC
may need a more detailed picture of resources on the MG.  This could be
handled by representing subsets of resource on the MG as pools.  Pools could
be named and pool name could be referenced as a level in a hierarchical
termination name.  The MGC will likely want to confirm that it's picture of
the MG resources has not gotten out of sync with the actual resources
available on the MG over time via a background audit.

Even for conferences that are not scheduled in advance  the MGC may still
want to direct a particular conference to the MG that is most likely to have
the resources available needed for that conference.  If participants are
added one at a time, the MG may want to reserve a certain number of
resources when it adds the first participant to the context.  Perhaps a
context property could be sent down with the first add so that the
appropriate number of resources could be reserved.

David
--
[email-masked]                   Nortel Networks Cable
Telephony Solutions, Inc. 
Tel:   919-991-8870  (esn 351)                     35 Davis Dr
Fax:  919-991-4088                                    RTP, NC 27709

> From:	Even ,Roni [SMTP:[email-masked]]
> Sent:	Sunday, August 19, 2001 2:52 AM

---

From: "David Cromwell" <[email-masked]>
Date: Mon, 20 Aug 2001 16:52:24 -0400

> Don makes a good point that maximum capacity is variable over time and
> based is on a number of different factors, transcoding requirements,
> mixing requirements, etc.  Since as Brian points out the MGC is not likely
> to have a detailed (or
> completely up to date)  picture of resources as the MG, the MG will need
> to do the finest level of granularity of resource allocation.
> 
> There seems to be general agreement that scheduled reservations are a
> requirement.  I agree with Brian that the MGC can keep track of resource
> availability on the MG and will do routing of calls and scheduled
> reservations based on internal bookkeeping.  This is particularly
> appropriate if the MGC is controlling more than one MG where a call can be
> routed to the MG with the most free resources.  If the MGC doesn't know
> all the details about the MG's resources, reservation/allocation should be
> based on the worst case resource requirements.
> 
> If an MG doesn't have the resources up front for a conference it should
> nack.  The suggestion to have context property to reserve resources is so
> that once you start up a conference, you are guaranteed to have the
> resources you need to finish building the conference.   At any point in
> time the MGC has a general picture of resources, but due the latency
> involved in auditing  as well as race conditions as calls are created and
> destroyed, only the MG knows the exact current state of its resources.  In
> effect you make the initial resource reservation on the MGC, and confirm
> the reservation on the MG.
> 
> It seems appropriate to nack a conference up front if there are no
> resources available.  The MGC then can try and create the conference
> elsewhere. However there doesn't seem to be a graceful  way for the MGC to
> back out of a partially built conference when the MG runs out of
> resources.  For example a customer has reserved a to 7 party bridge for 2
> hours beginning 10:00 am.  The first three participants that dial in are
> added, but then the MG runs out of resources.   In this case I see two
> options:  1.  Play a message to the conference and then tear it down, or
> 2.  Transparently destroy the conference and recreate it somewhere else.
> The first option is not likely to be acceptable from the customer's point
> of view.  The customer is not going to be happy since he paid for a 7
> party bridge and didn't get it. The second option does not seem practical
> since it would require renegotiation for the existing terminations.
> Reserving conference resources up front at conference creation time by
> using a context property would prevent the vast majority of these
> situations.
> 
> David
> --

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 20 Aug 2001 18:05:40 -0400

There isn't any need to have context properties - the MGC can create
ephemerals with
Media that does not have a network type/address, which will reserve the
resources but
not cause network traffic.  When actual connections are to be made, the MGC
Modifies Media to have the correct network type and addresses.  You can even
specify "worst case" transcoding!
 
Brian

-----Original Message-----
From: David Cromwell [mailto:[email-masked]]
Sent: Monday, August 20, 2001 4:46 PM
To: 'Rosen, Brian'; 'Don Stanwyck'; 'Even ,Roni'; 'Danny Levin'; 'Christian
Groves'; [email-masked]
Cc: Rodney Green

Don makes a good point that maximum capacity is variable over time and based
is on a number of different factors, transcoding requirements, mixing
requirements, etc.  Since as Brian points out the MGC is not likely to have
a detailed or

completely up to date picture of resources as the MG, the MG will need to do
the finest level of granularity of resource allocation.

There seems to be general agreement that scheduled reservations are a
requirement.  I agree with Brian that the MGC can keep track of resource
availability on the MG and will do routing of calls and scheduled
reservations based on internal bookkeeping.  This is particularly
appropriate if the MGC is controlling more than one MG where a call can be
routed to the MG with the most free resources.  If the MGC doesn't know all
the details about the MG's resources, reservation/allocation should be based
on the worst case resource requirements.

If an MG doesn't have the resources up front for a conference it should
nack.  The suggestion to have context property to reserve resources is so
that once you start up a conference, you are guaranteed to have the
resources you need to finish building the conference.   At any point in time
the MGC has a general picture of resources, but due the latency involved in
auditing  as well as race conditions as calls are created and destroyed,
only the MG knows the exact current state of its resources.  In effect you
make the initial resource reservation on the MGC, and confirm the
reservation on the MG.

It seems appropriate to nack a conference up front if there are no resources
available.  The MGC then can try and create the conference elsewhere.
However there doesn't seem to be a graceful  way for the MGC to back out of
a partially built conference when the MG runs out of resources.  For example
a customer has reserved a to 7 party bridge for 2 hours beginning 10:00 am.
The first three participants that dial in are added, but then the MG runs
out of resources.   In this case I see two options:  1.  Play a message to
the conference and then tear it down, or  2.  Transparently destroy the
conference and recreate it somewhere else.  The first option is not likely
to be acceptable from the customer's point of view.  The customer is not
going to be happy since he paid for a 7 party bridge and didn't get it. The
second option does not seem practical since it would require renegotiation
for the existing terminations.  Reserving conference resources up front at
conference creation time by using a context property would prevent the vast
majority of these situations.

David

---

From: "Even ,Roni" <[email-masked]>
Date: Tue, 21 Aug 2001 16:05:11 +0200

Hi,
 I agree with Brian, I would like to add that the MG may update the MGC
about current resources availability using service change
Roni Even

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Monday, August 20, 2001 7:17 PM
To: 'Don Stanwyck'; David Cromwell; 'Even ,Roni'; 'Danny Levin'; 'Christian
Groves'; [email-masked]
Cc: Rodney Green

The present mechanisms in Megaco are not sufficient for extremely fine
grained knowledge of
MG resources at the MGC.  One of the things that we are doing about this is
the SDPng effort,
which has a design goal to be able to pass on such knowledge.
 
So, to be really precise, it's true that the MG will have more knowledge
than the MGC on the
use of it's resources.  In practice, I think that it will be the case that
the MGC indeed does
track resources at the MG, and never asks for something that would not be
possible.  I think
the MG will track resource consumption, but if they are exhausted, it's a
non-recoverable error.
I don't think the idea of asking the MG to reserve resources is practical
(basically, if you
had a way to express what kinds of resources you wanted to reserve, then you
could
express what resources the MG had in the same terms).   In your example,
the MGC has no knowledge before a conference starts of what the requirements
for
codecs will be.   Of course, neither does the MG.  No one can do anything
but reserve
worst case requirements.  The MGC could do that by internal bookkeeping.
Having the MG 
have an active role in resource reservation is not usefull.
 
So, I think the audit has to reveal worst case resource availability, and
doing better won't help
much.
 
Brian

-----Original Message-----
From: Don Stanwyck [mailto:[email-masked]]
Sent: Monday, August 20, 2001 12:53 PM
To: David Cromwell; 'Even ,Roni'; 'Rosen, Brian'; 'Danny Levin'; 'Christian
Groves'; [email-masked]
Cc: Rodney Green

David, et al:
     A large IP-based conference bridge usually has a variable set of
resources depending on the demands made by endpoints to the conference.  For
example, if the streams to be mixed are all G.711 streams, there may be e.g.
10000 ports available.  If they are all G.729 streams, the number will be
significantly less, perhaps 7500.  And if they are a disparate mix of 4 or 5
codecs, the ports available may be fewer still.  It is not reasonable (or
likely even possible) to pass the resource management up to the MGC - so the
MGC can only be aware of the type of resources available and a current
number of remaining resources. Reservations should be possible, but they
must come with information about the types of resources that will be
required so that an appropriate mix of resources can be allocated.
Capabilities should be discoverable by the MGC, but the MGC will not be able
to do detailed resource allocation and management.
 
Don Stanwyck

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of David
Cromwell
Sent: Monday, August 20, 2001 9:25 AM
To: 'Even ,Roni'; 'Rosen, Brian'; 'Danny Levin'; 'Christian Groves';
[email-masked]'
Cc: Rodney Green
Subject: RE: [Megaco] How to control multimedia conference bridges

David 

	-----Original Message----- 
From:   Even ,Roni [SMTP:[email-masked]] 
Sent:   Sunday, August 19, 2001 2:52 AM 
To:     'Rosen, Brian'; Even ,Roni; 'Danny Levin'; 'Christian Groves';
[email-masked]' 

	Brian, 

	-----Original Message----- 
From: Rosen, Brian [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Friday, August 17, 2001 8:19 PM 
To: Even ,Roni; 'Danny Levin'; 'Christian Groves'; [email-masked]' 
Subject: RE: [Megaco] How to control multimedia conference bridges 

	Brian

---

From: "Larry Clarkson" <[email-masked]>
Date: Tue, 21 Aug 2001 09:49:51 -0400

One comment regarding resource tracking in the MG vs MGC.  The resource
limitations in the MG due to variances in per call loading could be coded in
the MGC as easily as the MG.  However, these restrictions are likely to vary
by MG since they're so directly related to the hardware technology.  They're
also likely to vary as a MGs hardware evolves.  Given this variance, perhaps
leaving this detailed tracking to the MG might make more sense.  The MG
could then provide the MGC with current information about its available
capacity in real time, piggy backing on top of existing call processing.

Larry Clarkson

	-----Original Message-----
	From:	Even ,Roni [SMTP:[email-masked]]
	Sent:	Tuesday, August 21, 2001 10:05 AM
	To:	[email-masked]'
	Subject:	RE: [Megaco] How to control multimedia conference
bridges

	Hi,
	 I agree with Brian, I would like to add that the MG may update the
MGC about current resources availability using service change
	Roni Even

		-----Original Message-----
		From: Rosen, Brian [mailto:[email-masked]]
		Sent: Monday, August 20, 2001 7:17 PM
		To: 'Don Stanwyck'; David Cromwell; 'Even ,Roni'; 'Danny
Levin'; 'Christian Groves'; [email-masked]
		Cc: Rodney Green
		Subject: RE: [Megaco] How to control multimedia conference
bridges

		The present mechanisms in Megaco are not sufficient for
extremely fine grained knowledge of
		MG resources at the MGC.  One of the things that we are
doing about this is the SDPng effort,
		which has a design goal to be able to pass on such
knowledge.
		 
		So, to be really precise, it's true that the MG will have
more knowledge than the MGC on the
		use of it's resources.  In practice, I think that it will be
the case that the MGC indeed does
		track resources at the MG, and never asks for something that
would not be possible.  I think
		the MG will track resource consumption, but if they are
exhausted, it's a non-recoverable error.
		I don't think the idea of asking the MG to reserve resources
is practical (basically, if you
		had a way to express what kinds of resources you wanted to
reserve, then you could
		express what resources the MG had in the same terms).   In
your example,
		the MGC has no knowledge before a conference starts of what
the requirements for
		codecs will be.   Of course, neither does the MG.  No one
can do anything but reserve
		worst case requirements.  The MGC could do that by internal
bookkeeping.  Having the MG 
		have an active role in resource reservation is not usefull.
		 
		So, I think the audit has to reveal worst case resource
availability, and doing better won't help
		much.
		 
		Brian

			-----Original Message-----
			From: Don Stanwyck [mailto:[email-masked]]
			Sent: Monday, August 20, 2001 12:53 PM
			To: David Cromwell; 'Even ,Roni'; 'Rosen, Brian';
'Danny Levin'; 'Christian Groves'; [email-masked]
			Cc: Rodney Green
			Subject: RE: [Megaco] How to control multimedia
conference bridges

			David, et al:
			     A large IP-based conference bridge usually has
a variable set of resources depending on the demands made by endpoints to
the conference.  For example, if the streams to be mixed are all G.711
streams, there may be e.g. 10000 ports available.  If they are all G.729
streams, the number will be significantly less, perhaps 7500.  And if they
are a disparate mix of 4 or 5 codecs, the ports available may be fewer
still.  It is not reasonable (or likely even possible) to pass the resource
management up to the MGC - so the MGC can only be aware of the type of
resources available and a current number of remaining resources.
Reservations should be possible, but they must come with information about
the types of resources that will be required so that an appropriate mix of
resources can be allocated.  Capabilities should be discoverable by the MGC,
but the MGC will not be able to do detailed resource allocation and
management.
			 
			Don Stanwyck

				-----Original Message-----
				From: [email-masked]
[mailto:[email-masked]]On Behalf Of David Cromwell
				Sent: Monday, August 20, 2001 9:25 AM
				To: 'Even ,Roni'; 'Rosen, Brian'; 'Danny
Levin'; 'Christian Groves'; [email-masked]'
				Cc: Rodney Green
				Subject: RE: [Megaco] How to control
multimedia conference bridges

				Agreed. Handling resource reservation on the
MG is not appropriate.  The MGC should discover the resources available on
the MG via an audit at MG startup.   The MGC would then keep track of the
available resources as calls come and go.  There is additional complexity if
the resources available on the MG are not ubiquitous, i.e. if a conference
is limited to a subset of the resources available on the MG, for example a
particular dsp or group of dsp's or a particular card or card set.  There
also may be partitioning of resources by functional type, e.g. audio, video,
etc.  In both cases the MGC may need a more detailed picture of resources on
the MG.  This could be handled by representing subsets of resource on the MG
as pools.  Pools could be named and pool name could be referenced as a level
in a hierarchical termination name.  The MGC will likely want to confirm
that it's picture of the MG resources has not gotten out of sync with the
actual resources available on the MG over time via a background audit.

				Even for conferences that are not scheduled
in advance  the MGC may still want to direct a particular conference to the
MG that is most likely to have the resources available needed for that
conference.  If participants are added one at a time, the MG may want to
reserve a certain number of resources when it adds the first participant to
the context.  Perhaps a context property could be sent down with the first
add so that the appropriate number of resources could be reserved.

				David 
				-- 
				[email-masked]
Nortel Networks Cable Telephony Solutions, Inc. 
				Tel:   919-991-8870  (esn 351)
35 Davis Dr 
				Fax:  919-991-4088
RTP, NC 27709 

				-----Original Message----- 
				From:   Even ,Roni
[SMTP:[email-masked]] 
				Sent:   Sunday, August 19, 2001 2:52 AM 
				To:     'Rosen, Brian'; Even ,Roni; 'Danny
Levin'; 'Christian Groves'; [email-masked]' 
				Subject:        RE: [Megaco] How to control
multimedia conference bridges 

				Brian, 
				I would like to be would like to be able to
find the capabilities of the 
				conferencing bridge like being able to
transcode and what codecs and how 
				many during bridge start up. this maybe
required for reserving conferences 
				by the MGC which knows the resources it can
use on all MGs that are 
				controlled by it. This information is needed
before the actual creation of 
				the context when the conference need to be
schedules. Otherwise, in order to 
				guarantee the reservation the MG must handle
the reservations. 
				Roni Even 

				-----Original Message----- 
				From: Rosen, Brian [
mailto:[email-masked] <mailto:[email-masked]> ] 
				Sent: Friday, August 17, 2001 8:19 PM 
				To: Even ,Roni; 'Danny Levin'; 'Christian
Groves'; [email-masked]' 
				Subject: RE: [Megaco] How to control
multimedia conference bridges 

				I think once we agree on requirements, we
can see how complex 
				the layering has to be.  I'm ever optimistic
we can make it 
				reasonably simple. 

				One thing you do get with layers is easy
audit; you do 
				an audit of packages and you can see what
layers are 
				implemented.  See the thread(s) on auditing
of 
				non-existent ephemerals for some issues. 

				One non-problem is transcoding.  That is all
in the SDP. 
				If the device can transcode, it will accept
SDP that allows 
				different ports to have different codecs.
If it can't, 
				it won't.  Nothing else is needed, I think. 

				Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 21 Aug 2001 11:47:12 -0400

There is no doubt that the MG will do fine-grained resource tracking.  For
example, DSP based MGs will
have estimates of available MIPs, and, based on codecs choices and numbers
of lines,
will track how many MIPS are left.  At the time you actually activate a
termination, you the MG decides
if it can do it, and if it can't it will return an error.
 
Actually, it's a little better than that, because when you actually try to
get the termination started,
you can ask what the termination can support (the "offer" SDP), which could
list what is possible
on that termination at that time.  All of that is standard Megaco.  I can't
think of how we would need
to extend that capability negotiation mechanism for conferencing, but we
could if we needed to.
 
The real issue is that you can't do anything with that resource tracking
other than change the offer
SDP.  You can't "reserve" resources unless you reserve worst case resources.
What we are saying
is that the MGC can do that, and the fine-grained resource accounting that
the MG does can only
be used in pretty limited ways as described above.
 
Basically, I propose we use existing mechanisms for resource tracking and
"reservations"
and not try to define new ones for conferencing.
 
Brian

-----Original Message-----
From: Larry Clarkson [mailto:[email-masked]]
Sent: Tuesday, August 21, 2001 9:50 AM
To: 'Even ,Roni'; [email-masked]'
Subject: RE: [Megaco] How to control multimedia conference bridges

Larry Clarkson 

	BM__MailData-----Original Message----- 
From:   Even ,Roni [SMTP:[email-masked]] 
Sent:   Tuesday, August 21, 2001 10:05 AM 
To:     [email-masked]' 
Subject:        RE: [Megaco] How to control multimedia conference bridges 

	Hi, 

	Roni Even 

	-----Original Message-----

  
  
Brian 

	-----Original Message-----
From: Don Stanwyck [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Monday, August 20, 2001 12:53 PM
To: David Cromwell; 'Even ,Roni'; 'Rosen, Brian'; 'Danny Levin'; 'Christian
Groves'; [email-masked]
Cc: Rodney Green
Subject: RE: [Megaco] How to control multimedia conference bridges

David, et al: 

Don Stanwyck 

	-----Original Message-----
From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ]On Behalf Of David Cromwell
Sent: Monday, August 20, 2001 9:25 AM
To: 'Even ,Roni'; 'Rosen, Brian'; 'Danny Levin'; 'Christian Groves';
[email-masked]'
Cc: Rodney Green
Subject: RE: [Megaco] How to control multimedia conference bridges

	Agreed. Handling resource reservation on the MG is not appropriate.
The MGC should discover the resources available on the MG via an audit at MG

	Even for conferences that are not scheduled in advance  the MGC may
still want to direct a particular conference to the MG that is most likely
to have the resources available needed for that conference.  If participants
are added one at a time, the MG may want to reserve a certain number of
resources when it adds the first participant to the context.  Perhaps a
context property could be sent down with the first add so that the
appropriate number of resources could be reserved.

	David

	-----Original Message-----
From:   Even ,Roni [SMTP:[email-masked]]
Sent:   Sunday, August 19, 2001 2:52 AM
To:     'Rosen, Brian'; Even ,Roni; 'Danny Levin'; 'Christian Groves';
[email-masked]'

	Brian,

	-----Original Message-----
From: Rosen, Brian [  <mailto:[email-masked]>
mailto:[email-masked]]
Sent: Friday, August 17, 2001 8:19 PM
To: Even ,Roni; 'Danny Levin'; 'Christian Groves'; [email-masked]'
Subject: RE: [Megaco] How to control multimedia conference bridges 

	Brian

---

From: Christian Groves <[email-masked]>
Date: Thu, 23 Aug 2001 14:29:09 +1000

Don't forget that we also have the "reserve group" and "reserve
property" indicators in local control. Its a way of indicating that some
resources have to be reserved.

Christian