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

From: Danny Levin <[email-masked]>
Date: Mon, 6 Aug 2001 19:27:55 -0500

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

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 07 Aug 2001 09:20:11 -0400

> You can add to a virtual endpoint only connections and not other endpoints.

Correct, but that's not an issue.

> What do you do if you need to add another physical endpoint to the

Recall that each endpoint has a connection associated with it. That goes for
physical as well as virtual endpoints. Furthermore, it is also independent of
which box(es) two communicating endpoints reside on. Thus, if I have a virtual
conferencing endpoint I simply create a connection on that virtual endpoint for
each party (endpoint) that should be part of the conference as illustrated
below:

e1 ----- vc ----- e2
         |
         |
         |
         e3

Each of e1, e2, and e3 has a connection, and vc has three connections.

A simpler (but less general) solution is to do the conferencing directly on one
of the physical endpoints, but it requires the endpoint to stay in the
conference for its entire duration, unless you implement the proposed
"MoveConnection" command from RFC 2705.

-- Flemming

--
Flemming Andreasen
Cisco Systems