Subject: Conferencing and MEGACO!!!!

From: Medha Vedaprakash <[email-masked]>
Date: Sat, 8 Apr 2000 15:51:18 -0400

Hi,

I'm looking for some information on providing conferencing support in the
MG,MGC. The Architecture and requirements document mentions the need to
support MP functionality in the MG and MC functionality in the MGC.

How're these related to the Context properties which is supposed to
contain "Media mixing and Switching properties" . However, there's no
formal representation of these Context properties anywhere in the
protocol spec.

Is there any other document that can be useful to me?

Thanks,
Medha

---

From: "Rosen, Brian" <[email-masked]>
Date: Sun, 9 Apr 2000 09:40:15 -0400

There is one explicit mechanism to support conferencing in Megaco,
and there are all the pieces to support another.

Look at the Topology mechanism.  If you had all of the legs of a
conference in a single context, topology can be used to control
who hears/sees/... whom.  That is enough to make a pretty straightforward
audio conference bridge.

It is also very reasonable to build a conference bridge with a set
of terminations, and make each leg a separate context.  That would
probably take a package definition, but I suspect that it would be pretty
simple to make one.

Brian

-----Original Message-----
From: Medha Vedaprakash
To: [email-masked]
Sent: 4/8/00 3:51 PM
Subject: Conferencing and MEGACO!!!!

Hi,

I'm looking for some information on providing conferencing support in
the
MG,MGC. The Architecture and requirements document mentions the need to
support MP functionality in the MG and MC functionality in the MGC.

Thanks,
Medha

---

From: David Cromwell <[email-masked]>
Date: Sun, 9 Apr 2000 13:21:09 -0400

Brian,

If as you suggest you built a conference bridge with a set of terminations
and made each leg a separate context where would the mixing take place? Are
you suggesting a mixing context which contains ephemeral terminations, each
of which is connected to an ephemeral termination in one of the leg
contexts?  If so, you could control the conference topology by using the
topology descriptor in the mixing context, however I am not clear what you
would gain by using multiple contexts v.s. using a single context.

Regards,
David
--
[email-masked]                   Nortel Networks Cable
Solutions
ESN:            351-8870                              35 Davis Dr
Public:    919-991-8870                              RTP, NC 27709

> From: Rosen, Brian [SMTP:[email-masked]]
> Sent: Sunday, April 09, 2000 9:40 AM
> To:   [email-masked]
> Subject:      Re: Conferencing and MEGACO!!!!
>

---

From: Priya A <[email-masked]>
Date: Mon, 10 Apr 2000 04:53:10 -0700

Hi,

*) If  Topology Descriptor is to be used to support
conferencing how to distinguish between multiple
streams , e.g. if a Termination is part of
Audio and Video conferences and  the topology of both
are different (i.e.  if "who hears whom" has to be
different from "who sees whom" ).

*) A Termination can be part of only one Context at a
time. That means if a Termination wants to be part of
two conferences simultaneously both the conferences
have to be part of the same context ?

Priya A
[email-masked]

"Rosen, Brian" wrote:

> who hears/sees/... whom.  That is enough to make a
pretty
straightforward
> probably take a package definition, but I suspect
that it would be
pretty
> Brian

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 10 Apr 2000 09:36:51 -0400

> different from "who sees whom" ).
Since topology is stream independent, if this was
a requirement, you could not use topology to control
the conference bridge.

> have to be part of the same context ?
You can only have one stream per media running to the user.
Therefore, you have to have all the audio or video for
one user in one stream.  I suppose the other end could mix,
but I assume you don't want that behavior.  It is certainly
possible to build such a media gateway.  The device
would have n ports, the ports can be combined any way your
hardware is capable of combining them.  Each port is one
termination.  The control of the bridge would have to be
by properties, which would be defined in a package.  There
is no such package designed yet, and I suspect that it
would be some time before we could get agreement on some
standard way to do this. In this design, each user is in
a separate context.

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 10 Apr 2000 09:54:12 -0400

If all you want is a simple mixing bridge, then you don't need the second
alternative I proposed.  However, as was pointed out, using the controls in
the protocol, you have some limits on how flexible you can make the
bridge.

If you want to go beyond the capabilities that the protocol provides, no
problem.  We have a very nice extension mechanism, the package.

I build a media gateway with n ports into a mixing bridge that has some
arbitrary capability.  Each user is connected to one port, and there are
a set of controls (properties) that define what that user hears/sees/etc.
We had the example of separate audio/video topology suggested for
example.  You could make a video mixer which showed the last four
speakers other than "yourself" in a grid.  Anything you want.
It's a completely general way to build any kind of bridge.  All I need do
is define a package with the controls I need for the bridge.  Of course,
I have to get some MGC(s) to implement the package!

     +------------+
 ----|            |---
     |            |
 ----|  Arbitrary |---
     |  Mixing    |
 ----|  Bridge    |---
     |            |
 ----|            |---
     +------------+

If you can use the protocol mechanisms, including topology, to get what
you want, I would think that would be the best way to control the MG,
when you can't, you can use the n termination, lots of properties
approach.

Brian

-----Original Message-----
From: David Cromwell [mailto:[email-masked]]
Sent: Sunday, April 09, 2000 1:21 PM
To: Rosen, Brian; [email-masked]
Subject: RE: Conferencing and MEGACO!!!!

Brian,

Regards,
David

        -----Original Message-----
From:   Rosen, Brian [SMTP:[email-masked]]
Sent:   Sunday, April 09, 2000 9:40 AM
To:     [email-masked]
Subject:        Re: Conferencing and MEGACO!!!!

        Brian

        -----Original Message-----
From: Medha Vedaprakash
To: [email-masked]
Sent: 4/8/00 3:51 PM
Subject: Conferencing and MEGACO!!!!

        Hi,

        I'm looking for some information on providing conferencing support
in
the
MG,MGC. The Architecture and requirements document mentions the need to
support MP functionality in the MG and MC functionality in the MGC.

        Thanks,
Medha

---

From: David Cromwell <[email-masked]>
Date: Mon, 10 Apr 2000 10:31:58 -0400

Comments below.

David
--
[email-masked]                   Nortel Networks
ESN:            351-8870                              35 Davis Dr
Public:    919-991-8870                              RTP, NC 27709

> Sent: Monday, April 10, 2000 9:54 AM
> alternative I proposed.
        [<dcc>]  Agreed.  I see most audio only conferencing inplementations
using this approach.

> However, as was pointed out, using the controls in
        [<dcc>]  I'm still unclear about how the context per leg thing
works.  Could you give an example?

> a set of controls (properties) that define what that user hears/sees/etc.
        [<dcc>]  So in this case the entire MG would support a single
context with individual conferences being defined by a really big topology
descriptor?

>       If as you suggest you built a conference bridge with a set of
> terminations and made each leg a separate context where would the mixing
> take place? Are you suggesting a mixing context which contains ephemeral
> terminations, each of which is connected to an ephemeral termination in
> one of the leg contexts?  If so, you could control the conference topology
> by using the topology descriptor in the mixing context, however I am not
> clear what you would gain by using multiple contexts v.s. using a single
> context.
>
>       Regards,
>       David
>       --

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 10 Apr 2000 15:54:15 -0400

Okay, I'll make a contrived example.  Suppose I wished to do what the
previous message did - allow users of my bridge to have a different set of
who hears whom from who sees whom.  Another example is a bridge that
allows user selection of multiple simultaneous translations, or allowing
users
to listen to an arbitrary set of conferences but speaking in only one at a
time.
Note that it is possible to use topology to do the latter two, by having all
users
in the same context and subsetting separate conferences by using topology
to make disjoint sets, it really is warping the mechanism to do so.

Anyway, let's take the first of those.  So, we build an MG that has a set of
(physical) terminations, one per port.  When a user wants to join, his call
control assigns him to one of the ports, so an ephemeral RTP termination is
created,
and we have a set of two terminations contexts (the bridge termination and
the
RTP termination).  We implement a package that has a stream dependent (i.e.
defined in LocalControl) parameter called "conferenceID".  The bridge is
built such that ports that have the same conferenceIDs have THAT STREAM
mixed with other ports with the same conferenceID.  Since it is stream
dependent,
you can be in a different audio conference than video conference.  The MGC
manages conference participation by manipulating the conferenceID parameter
in LocalControl.  Topology is normally set to BOTHWAYS for all streams.

Does that help?

Brian

-----Original Message-----
From: David Cromwell [mailto:[email-masked]]
Sent: Monday, April 10, 2000 10:32 AM
To: [email-masked]
Subject: Re: Conferencing and MEGACO!!!!

Comments below.

David

        -----Original Message-----
From:   Rosen, Brian [SMTP:[email-masked]]
Sent:   Monday, April 10, 2000 9:54 AM
To:     [email-masked]
Subject:        Re: Conferencing and MEGACO!!!!

        If all you want is a simple mixing bridge, then you don't need the
second
alternative I proposed.

        If you want to go beyond the capabilities that the protocol
provides, no
problem.  We have a very nice extension mechanism, the package.

     +------------+
 ----|            |---
     |            |
 ----|  Arbitrary |---
     |  Mixing    |
 ----|  Bridge    |---
     |            |
 ----|            |---
     +------------+

Brian

        -----Original Message-----
From: David Cromwell [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Sunday, April 09, 2000 1:21 PM
To: Rosen, Brian; [email-masked]
Subject: RE: Conferencing and MEGACO!!!!

        Brian,

        Regards,
David

                -----Original Message-----
From:   Rosen, Brian [SMTP:[email-masked]]
Sent:   Sunday, April 09, 2000 9:40 AM
To:     [email-masked]
Subject:        Re: Conferencing and MEGACO!!!!

                There is one explicit mechanism to support conferencing in
Megaco,
and there are all the pieces to support another.

                Look at the Topology mechanism.  If you had all of the legs
of a
conference in a single context, topology can be used to control
who hears/sees/... whom.  That is enough to make a pretty straightforward
audio conference bridge.

                It is also very reasonable to build a conference bridge with
a set
of terminations, and make each leg a separate context.  That would
probably take a package definition, but I suspect that it would be pretty
simple to make one.

                Brian

                -----Original Message-----
From: Medha Vedaprakash
To: [email-masked]
Sent: 4/8/00 3:51 PM
Subject: Conferencing and MEGACO!!!!

                Hi,

                I'm looking for some information on providing conferencing
support in
the
MG,MGC. The Architecture and requirements document mentions the need to
support MP functionality in the MG and MC functionality in the MGC.

                How're these related to the Context properties which is
supposed to
contain "Media mixing and Switching properties" . However, there's no
formal representation of these Context properties anywhere in the
protocol spec.

                Thanks,
Medha

---

From: David Cromwell <[email-masked]>
Date: Mon, 10 Apr 2000 18:29:25 -0400

Brian,

See comment below.

Regards,
David

> Sent: Monday, April 10, 2000 3:54 PM
> Note that it is possible to use topology to do the latter two, by having
> all users
> control assigns him to one of the ports, so an ephemeral RTP termination
> is created,

        [<dcc>]  Yes it does, particularly after we talked on the phone
about it!  Previously I was a little unclear that what you were talking
about was a whole bunch of two context terminations, each containing a
mixing termination and an RTP termination.  The n termination with lots of
properties on the non-RTP termination model makes sense for
hardware/application functionality that stretches the bounds of the normal
MEGACO connection model.  Thanks for talking the time to make this clear.

>               [<dcc>]  Agreed.  I see most audio only conferencing
> inplementations using this approach.
>
>               [<dcc>]  I'm still unclear about how the context per leg
> thing works.  Could you give an example?
>
>
>               [<dcc>]  So in this case the entire MG would support a
> single context with individual conferences being defined by a really big
> topology descriptor?
>
>               From: David Cromwell [ <mailto:[email-masked]>]
>               If as you suggest you built a conference bridge with a set
> of terminations and made each leg a separate context where would the
> mixing take place? Are you suggesting a mixing context which contains
> ephemeral terminations, each of which is connected to an ephemeral
> termination in one of the leg contexts?  If so, you could control the
> conference topology by using the topology descriptor in the mixing
> context, however I am not clear what you would gain by using multiple
> contexts v.s. using a single context.
>
>                       Regards,
>               David
>               --
>               [email-masked]                   Nortel
> Networks Cable Solutions
>               ESN:            351-8870                              35
> Davis Dr